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I.  INTRODUCTION 


A.  THE  PROBLEM 

The  U.  S.  Naval  Supply  Depot  Yokosuka,  Japan  ( NSD 
Yokosuka),  is  tasked  with  providing  logistics  support  to 
U. S.  Navy  fleet  units  and  shore  activities  in  the  Japan  and 
Northern  Pacific  operating  areas.  As  the  major  U. S.  Navy 
logistics  installation  in  Japan,  NSD  Yokosuka  is  the  primary 
source  of  logistics  support  for  all  Navy  and  Marine  Corps 
shore  activities  based  in  Japan.  Fleet  units  supported  by 
NSD  Yokosuka  include  eleven  homeported  ships  as  well  as 
deployed  ships  of  the  Seventh  Fleet.  •  Although  NSD 
Yokosuka's  major  function  is  material  support,  it  also 
provides  essential  supply  services.  The  Freight  Terminal 
Division  is  responsible  for  transshipment  to  the  requisi- 
tioner  of  issue  priority  group  one  material  received  from 
stateside  Naval  Supply  Centers  and  Defense  Logistics  Agency 
(DLA)  activities.  The  Depot  also  manages  a  variety  of  other 
support  services  including  contracting,  data  processing, 
accounting,  disbursing  and  personal  property  shipment. 

In  addition  to  its  basic  fleet  support  role,  NSD 
Yokosuka  is  tasked  with  tri-service  support  responsibilities 
for  fuel  and  subsistence.  NSD  Yokosuka  is  the  DLA 
Designated  Specialized  Support  Point  for  provisions  in 
Japan,  providing  subsistence  support  to  all  fleet  units,  DoD 
commissaries  and  troops  in  the  Japan  operating  area.  As  the 
DLA  agent  for  fuel,  NSD  Yokosuka  operates  the  largest  fuel 
complex  in  the  Pacific.  The  Fuel  Department  provides  bulk 
petroleum  products  to  all  military  activities  in  the  Western 
Pacific  and  maintains  Prepositioned  War  Reserve  Stock  ( PWRS ) 
inventory  levels  to  meet  the  anticipated  combined  require¬ 
ments  of  the  services  in  that  area. 


NSD  Yokosuka  is  strategically  positioned  to  support 
contingency  operations  in  the  Far  East.  Any  conflict  in  the 
Northern  Pacific,  Korea,  or  other  Southeast  Asian  country 
requiring  extensive  deployment  of  ships,  aircraft  and  troops 
will  result  in  a  surge  of  activity  for  NSD  Yokosuka.  If  the 
conflict  is  not  short-term  in  duration,  the  increased  oper¬ 
ating  tempo  could  be  expected  to  result  in  new  manpower 
requirements,  multi-shift  operation  of  the  NSD  and  its 
detachments,  possible  expansion  of  physical  storage  facili¬ 
ties  and  the  acquisition  of  additional  material  handling 
equipment.  NSD  Yokosuka' s  ability  to  respond  to  a  surge  in 
demand  for  logistics  support  brought  about  by  a  period  of 
increased  tension  or  open  conflict  is  a  critical  issue  to 
planning  military  operations  in  the  Far  Eastern  theater.  The 
NSD's  effectiveness  in  this  type  of  scenario  hinges  on  its 
ability  to  escalate  operations  in  a  short  time  frame. 
Counter  to  the  rapid  response  required  of  NSD  Yokosuka  in  a 
contingency  situation  is  the  relative  difficulty  of  mobi¬ 
lizing  the  necessary  manpower  and  other  resources  on  short 
notice.  Planning  specific  requirements  in  advance  and  iden¬ 
tifying  sources  to  fill  those  needs  is  essential  to  main¬ 
taining  supply  readiness  at  NSD  Yokosuka. 

Predicting  future  resource  requirements  of  the  Depot  is 
a  primary  function  of  the  Planning  and  Comptroller 
Department,  more  specifically,  the  Planning  Division.  In  any 
operating  environment,  NSD  Yokosuka  seeks  to  minimize  the 
processing  time  associated  with  issuing  material  to 
customers  while  maximizing  the  availability  of  other  support 
services  required.  To  this  end,  the  Planning  Division 
projects  the  volume  of  demand  that  the  Depot  will  be 
expected  to  support  in  various  operational  scenarios,  i.  e.  , 
positioning  of  an  additional  carrier  battle  group  or  a 
build-up  in  troop  levels.  Divisional  requirements  in 
support  of  those  levels  of  operation  are  estimated.  The 


consolidated  requirements  of  the  Depot  are  quantified  and 
plans  outlining  the  allocation  of  resources  among  divisions 
are  formulated. 


B.  THESIS  OBJECTIVE 

The  objective  of  this  thesis  is  to  provide  a  predictive 
and  quantitative  tool  to  support  the  contingency  planning 
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efforts  oJy^NSD^Yokosuka,'.-^ vA  computer  program^  modeling  the 
issue  processing  functions  of  the  Depot  wi-li  fee  constructed, 
^he  program  will  be  written  "  in  IBM's  General  Purpose 
Simulation  System  V  (GPSS  V).  The  completed  program  may  be 
used  to  conduct  experiments  simulating  Depot  performance 
under  conditions  of  surge  demand.  The  information  gathered 
in  a  controlled  series  of  experiments  with  the  model  can  be 
used  to  help  formulate  operating  policy  and  resource  distri¬ 
bution  plans  to  cope  with  contingency  situations."^ 


C.  SCOPE 

The  scope  of  the  model  will  be  limited  to  those  func¬ 
tions  of  NSD  Yokosuka  in  direct  support  of  issue  processing 
operations,  from  requisition  receipt  to  the  point  of  avail¬ 
ability  of  the  issue  for  shipment  to  the  requisitioner  (or 
the  point  of  actual  delivery  to  the  requisitioner  in  the 
case  of  bearer  walkthroughs,  quick  picks  and  issues  deliv¬ 
ered  to  Naval  Base  Yokosuka  activities  by  NSD  tractor 
trains )V\A  detailed  list  of  the  actual  processes  to  be  simu¬ 
lated  is  provided  in  Chapter  IV.  Other  Depot  operations 
have  been  excluded  for  the  following  reasons: 

1.  The  complexity  of  a  model  can  be  expected  to  increase 


stream  issue  processing  functions  will  provide  impor¬ 
tant  information  to  analysts  while  keeping  model 
modification  and  experimentation  within  the  capability 
of  personnel  without  extensive  simulation  experience. 

The  scope  of  the  system  to  be  simulated  is  also 


limited  by 
ware  on  wni 
ments  of  a 
functions  o 
of  memory  a 


by  the  capabilities  of  the  software  and  hard- 
wnich  it  is  implemented.  The  memory  require- 
f  a  program  written  to  simulate  all  major 
s  of  the  Depot  would  exceed  the  maximum  amount 
y  addressable  by  GPSS  V. 


9 


3.  Model  design  and  validation  imposes  substantial  data 
collection  responsibilities  on  the  NSD  Planning 
Division.  Depot  personnel  resources  were  taxed  to  meet 
the  data  requirements  imposed  during  development  of 
the  model  of  issue  proces*sing  functions. 

4.  Some  functions  of  the  Depot  are  sufficiently  complex 
to  form  the  basis  of  major  simulation  projects  by 
themselves.  Inventory  Control  Department,  Data 
Processing  Service  Center  (DPSC)  and  Freight  Terminal 
Division  operations  are  all  candidates  for  separate 
simulation  projects. 

5.  Mot  all  systems  can  be  simulated  with  discrete  simula¬ 
tion  methods.  The  Fuel  Department  manages  several 

?rocesses  that  are  best  modeled  by  continuous  simula- 
ion  methods. 


D.  LIMITATIONS 

1.  Data  Collection 

Construction  and  validation  of  the  model  was 
hampered  by  difficulties  experienced  by  the  author  during 
data  collection.  Due  to  the  physical  separation  of  NSD 
Yokosuka  from  the  Naval  Postgraduate  School,  the  data 
collection  effort  was  managed  by  the  NSD  Planning  Division. 
Personnel  from  cognizant  divisions  of  the  Depot  were  tasked 
with  collecting  the  data  from  retained  records  or  by  obser¬ 
vation  of  the  physical  processes.  The  time-intensive  nature 
of  random  sampling  slowed  the  process  of  data  collection. 
This  was  aggravated  by  competing  operational  requirements  in 
the  Inventory  Control  and  Material  Departments.  At  the  time 
of  this  writing.  the  collection  of  service  time  samples  for 
the  Packing  Section  and  half  of  the  material  storage  areas 
remained  incomplete. 

2.  Microcomputer  Simulation 

The  initial  objective  of  this  thesis  was  to  model 
NSD  issue  processing  operations  on  a  microcomputer.  Efforts 
in  that  direction  were  blocked  by  the  memory  requirements  of 


the  program.  The  technical  details  of  this  limitation  are 
discussed  briefly  in  Chapter  II  of  the  thesis. 

E.  ORGANIZATION  OF  THESIS 

The  balance  of  this  thesis  is  devoted  to  the  examination 
of  simulation  as  a  logistics  planning  tool  and  to  the  devel¬ 
opment  and  validation  of  a  program  to  be  used  for  simulation 
experimentation.  In  Chapter  II,  the  suitability  of  simula¬ 
tion  and  other  operations  research  disciplines  to  supporting 
logistics  planning  efforts  is  reviewed.  A  description  of 
issue  processing  at  NSD  Yokosuka,  the  system  to  be  modeled, 
forms  the  basis  of  Chapter  III.  Chapter  IV  utilizes  GPSS 
block  diagrams  to  explain  the  simulation  program  structure. 
Program  verification  and  a  discussion  of  program  validation 
are  presented  in  Chapter  V.  Guidance  in  experimentation 
techniques  and  a  discussion  of  simulation  experiments 
conducted  by  the  author  are  included  in  Chapter  VI. 
Recommendations  and  conclusions  in  Chapter  VII  will  address 
further  simulation  experimentation  and  the  observed  benefits 
of  simulation  in  supporting  logistics  planners. 
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A.  OPERATION  RESEARCH 

NSD  Yokosuka's  ability  to  provide  the  level  of  logistics 
support  required  by  DoD  activities  in  the  Japan  operating 
area  is  a  product  of  the  combined  efforts  of  several  work- 
centers.  The  DPSC  Department  and  the  Customer  Services, 
Requirements,  Storage,  Labor  and  Equipment  and  Freight 
Terminal  Divisions  all  perform  tasks  integral  to  the 
processing  of  requisitions  received  by  NSD  Yokosuka. 
Because  a  decision  made  in  one  division  may  affect  the  oper¬ 
ations  of  another,  the  performance  of  individual  divisions 
must  be  evaluated  in  terms  of  their  contribution  to  overall 
Depot  performance.  This  interaction  between  functional  areas 
must  be  taken  into  account  by  the  Planning  Division  during 
the  formulation  of  operating  strategies  for  surge  demand 
environments.  Operations  research  techniques  incorporate 
the  systems  approach  and  can  serve  as  an  important  logistics 
planning  tool. 

Operations  research  is  a  collection  of  mathematical 
tools  that  may  be  applied  to  solve  practical  decision  prob¬ 
lems  within  a  system  [  Ref.  1]  .  The  aim  of  operations 
research  analysis  is  to  evaluate  the  probable  consequences 
of  decision  choices.  These  choices  are  typically  concerned 
with  the  allocation  of  scarce  resources  within  the  system. 
Most  methods  of  operations  research  use  models  to  study  the 
actual  system  [Ref.  2:  p.  4].  Models  represent  objects  of 
interest  within  the  system  as  entities,  the  characteristics 
of  entities  as  attributes  and  the  interactions  causing 
change  within  the  system  as  activities.  Models  are  employed 
when  experimentation  with  the  actual  system  is  not  a  prac¬ 
tical  approach  to  analyzing  operations.  Accordingly,  formu¬ 
lation  of  a  model  is  a  suitable  method  of  predicting  the 


performance  of  a  supply  depot  under  conditions  of  surge 
demand. 

Specialized  operations  research  techniques  have  evolved 
to  handle  certain  well-defined  classes  of  systems  problems. 
Network  analysis  may  be  used  to  solve  transportation  prob¬ 
lems.  Inventory  algorithms  are  used  to  make  inventory 
control  decisions.  These  techniques  are  well  suited  to 
narrowly-defined  problems  and  are  regularly  employed  by  the 
military  to  solve  logistics  problems.  The  study  of  broader, 
less  well-defined  systems  require  more  generalized  mathemat¬ 
ical  techniques. 

Mathematical  analysis  is  applied  to  systems  management 
problems  by  representing  attributes  of  the  system  as  vari¬ 
ables  and  activities  as  mathematical  functions  that  interre¬ 
late  the  variables  f Ref .  3:  pp.  8-9).  Mathematical  analysis 
is  a  sophisticated  operations  research  technique  that  can  be 
used  only  by  analysts  with  extensive  backgrounds  in  mathe¬ 
matics.  It  is  not  always  possible  to  formulate  a  complete 
mathematical  model  of  a  complex  system.  The  combined  effects 
of  uncertainty,  dynamic  interaction  between  decisions, 
interdependency  among  variables  and  the  representation  of 
processes  over  long  time  horizons  are  difficult  to  represent 
mathematically  and  may  require  alternative  methods  of 
research  [Ref.  4:  p.  142].  Stock  point  analysis  problems 
fall  into  this  category.  The  stochastic  nature  of  requisi¬ 
tion  arrival  and  processing  times,  overlap  between  the  oper¬ 
ations  of  separate  divisions  within  a  supply  depot,  the 
relationship  of  requisition  priority  and  type  to  the 
processing  procedures  followed  and  the  need  to  observe  oper¬ 
ations  over  extended  periods  of  time  all  support  the  use  of 
computer  simulation  as  a  research  tool. 

B.  SIMULATION 

Simulation  is  the  process  of  designing  a  model  that 
duplicates  the  dynamic  behavior  of  the  essential 


13 


characteristics  of  a  system  for  the  purpose  of  studying  that 
system  [Ref.  5].  It  is  a  popular  technique  among  operations 
research  practitioners.  In  a  survey  by  Weston  [Ref.  6]  of 
1000  U.  S.  firms,  it  was  the  most  frequently  employed 
quantitative  tool.  Simulation  is  also  used  extensively  by 
the  military  to  evaluate  weapons  and  logistics  systems. 
Because  the  structure  of  a  simulation  model  bears  a  close 
relation  to  the  logical  structure  of  the  real  system,  model 
development  is  simplified.  Schmidt  [Ref.  7]  notes  that  the 
level  of  mathematical  sophistication  required  to  develop  a 
simulation  model  of  a  complex  system  is  generally  less 
extensive  than  that  required  to  develop  a  mathematical 
model,  underscoring  simulation's  relative  ease  of  use.  It  is 
this  simplicity  that  makes  simulation  intuitively  popular  to 
analysts. 

Simulation  is  a  versatile  operations  research  technique. 
It  may  be  used  as  a  descriptive  tool  (to  describe  a  current 
system)  or  as  a  predictive  tool  (to  explore  a  hypothetical 
system  or  design  improvements  to  a  current  system). 
Simulation  is  also  flexible  with  respect  to  changes  in  the 
actual  system.  Variables  can  be  modified  before  a  simulation 
is  run,  or  dynamically,  to  align  the  model  with  real  system 
conditions. 

There  are  drawbacks  to  the  use  of  simulation.  Simulation 
does  not  optimize  in  the  sense  that  calculus-based  analyt¬ 
ical  methods  do  [Ref.  3:  p.  38].  Optimal  solutions  may  be 
obtained  only  through  repetition  of  simulation  experiments. 
Simulation  models  produce  less  precise  results  than  does 
mathematical  analysis  [Ref.  2:  p.  13].  Due  to  the  probabi¬ 
listic  nature  of  simulation,  the  results  of  simulation 
experiments  repeated  in  succession  can  be  expected  to  vary 
and  the  sensitivity  of  a  simulation  model  to  changes  in  the 
value  of  input  variables  is  not  subject  to  exact  measure¬ 
ment.  Simulation  models  experience  the  same  problems  as 
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models  employed  in  other  techniques  of  operations  research. 
They  may  appear  to  accurately  reflect  the  real  system,  when 
in  fact,  they  do  not.  Simulation  models,  as  all  others,  will 
yield  incorrect  results  if  they  are  not  validated  carefully. 

There  are  two  major  types  of  simulation,  continuous  and 
discrete  [Ref.  4:  p.  143].  Continuous  simulation  is 
concerned  with  systems  that  change  continuously  with  respect 
to  time  and  with  measurements  that  are  not  restricted  to 
integers.  Refinery  operations  and  rocket  trajectories  are 
examples  of  systems  that  are  studied  by  the  use  of  contin¬ 
uous  simulation.  In  discrete  simulation,  the  simulated  time 
advances  in  a  stepwise  discrete  fashion.  A  discrete  simula¬ 
tion  is  time-oriented  if  the  simulation  clock  is  updated  at 
regular  time  intervals.  If  the  clock  is  updated  by  the 
scheduled  occurrence  of  events,  the  simulation  is  termed 
event-oriented.  Discrete  event  simulation  lends  itself 
especially  well  to  the  modeling  of  queuing  systems  and, 
therefore,  is  generally  applicable  to  modeling  the  perform¬ 
ance  of  service  organizations  that  can  be  represented  as  a 
collection  of  service  facilities  and  queues  [Ref.  8]. 

Discrete  event  simulation  is  frequently  used  to  model 
military  supply  depot  operations.  The  use  of  discrete  event 
simulation  as  a  forecasting  tool  offers  several  advantages 
to  logistics  planners.  Queue  statistics  gathered  during  the 
simulation  pinpoint  processing  bottlenecks  that  may  be 
expected  to  occur.  Server  utilization  statistics  collected 
for  each  functional  area  may  be  used  to  support  resource 
allocation  decisions.  System  throughput  data  can  be  quanti¬ 
fied  by  measuring  the  processing  time  for  the  different 
classes  of  requisitions  passing  through  the  system.  In 
addition,  the  model  may  be  easily  modified  to  reflect 
increasing  levels  of  demand,  changes  in  net  effectiveness  or 
the  addition  of  personnel. 
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C.  SIMULATION  LANGUAGES 


Discrete  event  simulation  programs  may  be  written  in  a 
general  purpose  programming  language  like  FORTRAN  or  PASCAL, 
or  in  a  special  purpose  simulation  language.  As  computer 
simulation  evolved  as  an  operations  research  technique  in 
the  late  1950s,  all  simulations  were  written  in  general 
purpose  or  specific-machine  languages.  As  researchers  began 
to  recognize  the  fact  that  many  situations  being  simulated 
were  composed  of  functionally  similar  processes,  the  need  to 
develop  special  purpose  languages  in  which  single  operators 
would  perform  common  functions  became  apparent.  Emshoff  and 
Sisson  [Ref.  9:  p.  116]  enumerated  the  functions  common  to 
all  simulations  that  distinguish  simulation  languages  from 
general  purpose  programming  languages: 

1.  create  random  numbers 

2.  create  random  variates 

3.  advance  time,  either  by  one  unit  or  to  the  next  event 

4.  record  data  for  output 

5.  perform  statistical  analyses  on  recorded  data 

6.  arrange  outputs  in  specified  formats 

7.  detect  and  report  logical  inconsistencies  and  other 
error  conditions 

Kiviat  [Ref.  10]  cited  programming  convenience  and 
concept  articulation  as  the  two  major  advantages  of  using  a 
simulation  language  as  opposed  to  a  general  purpose 
language. 

Concept  articulation  refers  to  the  ability  of  simulation 
languages  to  communicate  the  structure  of  a  system  being 
modeled  through  the  use  of  a  descriptive  vocabulary.  This  is 
especially  important  to  analysts  in  the  model  development 
^  phase.  It  also  improves  communication  in  that  simulations 

are  more  easily  explained  to  management  and  other  non¬ 
programming  oriented  users. 

The  programming  convenience  of  simulation  languages  is 
evidenced  by  the  reduction  in  both  program  length  and 
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development  effort  required.  Jennergren  [Ref.  11]  concluded 
that  simulation  programs  written  in  PASCAL  average  twice  the 
length  of  their  simulation  language  counterparts.  Emshoff 
and  Sisson  [Ref.  9:  p.  117]  estimate  the  savings  in  model 
development  effort  resulting  from  the  use  of  simulation 
languages  to  be  on  the  order  of  a  factor  of  10.  Several 
factors  contribute  to  the  programming  convenience  of 
simulation  languages.  The  subroutines  provided  as  standard 
features  of  simulation  languages  provide  programmers  with 
simple  tools  to  represent  simulation-unique  functions  and 
concepts.  The  ease  with  which  simulation  languages  define 
classes  of  system  entities,  differentiate  among  entities 
within  those  classes  and  permit  adjustment  of  the  number  or 
type  of  entities  in  the  system  is  also  helpful.  The 
convenience  of  simulation  languages  is  not  achieved  without 
sacrifice.  The  structuring  of  entities  and  activities  in 
simulation  languages  increases  their  flexibility  in  that 
changes  to  the  system  require  only  simple  modifications  to 
the  program.  These  generalized  structures,  however,  limit 
the  ability  of  simulation  languages  to  represent  system 
detail.  Though  simulation  languages  automatically  collect 
and  display  data  generally  desired  by  analysts,  they  are 
less  flexible  than  general  purpose  programming  languages 
with  respect  to  the  variety  of  output  formats.  Finally, 
programs  written  in  simulation  languages  can  expect  to 
experience  slower  execution  times  than  general  purpose 
language  programs. 

The  initial  concern  of  most  organizations  in  the  process 
of  selecting  a  simulation  language  is  ensuring  that  the 
chosen  language  is  compatible  with  installed  hardware  and 
that  its  use  is  within  the  capability  of  the  organization's 
analysts.  Other  questions  should  be  answered  in  the  second 
phase  of  the  selection  process.  The  relative  ease  of 
learning,  availability  of  users  manuals,  machine 
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portability,  quality  of  error  diagnostics,  language 
efficiency  and  cost  of  the  languages  under  consideration 
should  be  explored.  Finally,  the  ability  of  the  chosen 
simulation  language  to  naturally  describe  the  system  in 
question  should  be  studied.  The  suitability  of  a  simulation 
language  to  a  given  problem  may  be  assessed  by  examining  its 
"world  view. " 

The  world  view  of  a  simulation  language  is  the  way  that 
it  conceptualizes  the  entities  of  a  system,  the  attributes 
that  further  describe  those  entities,  and  the  interaction 
between  those  entities  and  the  activities  of  the  system 
[  Ref.  12:  p.  17]  .  World  views  of  simulation  are  grouped 
into  two  schools  of  simulation  thought,  one  emphasizing  the 
use  of  flowcharts  to  describe  models,  the  other  relying  on 
program  statements. 

Flowchart  languages  are  regarded  by  users  as  somewhat 
easier  to  learn  and  interpret,  while  statement  oriented 
languages  are  more  flexible  (Ref.  12:  p.  18].  Statement 
oriented  languages  are  characterized  by  three  world  views-- 
activity,  event  and  process.  Flowchart  oriented  simulation 
languages  adhere  to  the  transaction  world  view.  The  trans¬ 
action  world  view  models  systems  by  tracing  the  flow  of 
transactions  through  specialized  activity  blocks.  Simulated 
time  advances  as  transactions  pass  through  the  blocks  which 
are  used  to  represent  actual  processes  or  real  system  deci¬ 
sions.  Users  familiar  with  flowcharting  techniques  and  the 
system  being  modeled  find  the  transaction  view  convenient  to 
use  and  easy  to  learn.  IBM's  GPSS  is  the  predominant 
language  in  this  category. 

D.  GPSS 

The  transaction  world  view  of  GPSS  is  structurally 
similar  to  the  complex  queuing  problems  posed  by  requisition 
flow  in  a  supply  depot.  GPSS  uses  block  diagrams  to  visu¬ 
alize  transactions  moving  from  process  to  process  within  the 


system.  Each  GPSS  block  is  implemented  by  a  code  segment 
representing  an  action  relative  to  the  system  simulation. 
The  close  relationship  between  the  block  diagram  and  program 
code  to  the  logical  structure  of  the  system  being  simulated 
makes  GPSS  easy  to  use.  System  throughput,  resource  utili¬ 
zation  and  queuing  statistics  collected  as  standard  features 
of  GPSS  may  be  tailored  to  support  the  information  require¬ 
ments  of  the  logistics  planner. 

GPSS  is  particularly  attractive  to  the  inexperienced 
user.  The  block  diagram  structure  reduces  the  complexity  of 
model  development  and  communicates  an  understanding  of  the 
simulation  program  to  users.  Statistics  gathering  and 
display  require  minimal  effort  on  the  part  of  the  user. 
Because  GPSS  is  the  most  popular  and  widely  used  simulation 
language  [Ref.  13],  numerous  companies  market  GPSS  products 
and  provide  comprehensive  documentation.  In  addition  several 
academic  texts  on  GPSS  have  been  published,  offering  another 
source  of  information  to  users. 

Minuteman  Software  has  developed  a  microcomputer  version 
of  GPSS,  marketed  under  the  name  of  GPSS/PC,  to  take  advan¬ 
tage  of  the  increased  CPU  and  memory  capacities  of  modern 
microcomputers.  Designed  for  use  on  IBM  compatible  microcom¬ 
puters,  the  structure  and  syntax  of  GPSS/PC  are  nearly  iden¬ 
tical  to  that  of  the  mainframe  version,  enabling  it  to 
retain  its  attractiveness  as  a  discrete  event  simulation 
language.  The  primary  advantages  of  using  a  simulation 
language  designed  for  the  microcomputer  are  reduced  software 
expenses  and  the  convenience  to  the  analyst  of  working  on  a 
dedicated  microcomputer.  While  the  general  design  of  GPSS/PC 
is  suited  to  the  simulation  of  supply  depot  operations,  it 
is  constrained  by  its  inability  to  to  address  more  than  640 
kilobytes  of  random  access  memory,  a  limit  shared  by  all 
applications  programs  running  on  IBM's  Disk  Operating  System 
(DOS).  Due  to  this  inherited  limitation,  GPSS/PC  is  not 


CV  v\  '.v. 


■Im* 


19 


useful  in  the  simulation  of  large  queuing  systems  such  as 
NSD  Yokosuka. 

Discrete  event  simulation,  utilizing  GPSS,  could  be 
effectively  used  to  support  logistics  planning  efforts  of 
NSD  Yokosuka.  Note  the  following  points: 

1.  Issue  processing  procedures  at  NSD  Yokosuka  are 

permeated  with  the  type  of  queuing  phenomena  that 

discrete  event  simulation  languages,  GPSS  in  partic¬ 
ular,  are  designed  to  model. 

2.  The  standard  format  of  discrete  simulation  output  is 

suited  to  the  information  requirements  of  Depot 

planners. 

3.  Experimentation.  including  minor  modifications,  with 
existing  simulation  models  is  within  the  capability  of 
analysts  in  the  NSD  Yokosuka  Planning  Division. 

4.  The  block  diagram  structure  of  GPSS  improves  user 

understanding  of  program  structure,  easing  the  process 
of  making  program  modifications  required  by  changes  in 
NSD  facilities  or  procedures. 

5.  Owing  to  its  popularity,  GPSS  documentation,  training, 
and  technical  assistance  are  all  readily  available  to 
the  NSD 

While  discrete  event  simulation  can  be  a  useful  tool  to 
logistics  planners,  its  disadvantages  must  also  be  recog¬ 
nized.  Drawbacks  to  the  use  of  computer  simulation  in  logis¬ 
tics  planning  include: 

1.  Validating  a  simulation  model  requires  substantial 
effort  and  is  a  continuing  process  as  the  model  must 
be  maintained  to  reflect  real  system  changes.  If  the 
basic  model  does  not  accurately  reflect  actual  system 
operations  or  supporting  data  is  erroneous,  simulation 
results  will  not  be  useful. 

2.  Though  experimentation  and  minor  modifications  are 
within  the  capability  of  NSD  Yokosuka  personnel,  major 
revision  would  require  outside  training  or  assistance. 

3.  Because  the  simulation  model  is  a  simplification  of 
the  actual  system,  detail  useful  to  planners  is  lost. 
In  addition.  limiting  the  scope  of  the  model  leaves 

Planners  without  information  on  other  essential  Depot 
unctions. 

The  practical  limitations  of  discrete  event  simulation  must 
be  accepted  before  it  is  employed  as  a  logistics  planning 
tool.  In  combination  with  other  operations  research 
techniques,  discrete  event  simulation  using  GPSS  can  be  an 
effective  method  of  forecasting  NSD  Yokosuka  performance 
under  conditions  of  surge  demand. 


III.  THE  SYSTEM  12  EE  MODELED 

NSD  Yokosuka's  main  administrative  offices  and  storage 
facilities  are  located  on  U.  S.  Naval  Base  Yokosuka,  of 
which  the  NSD  is  a  tenant  activity.  Figure  3. 1  shows  the 
physical  layout  of  NSD  facilities  on  Naval  Base  Yokosuka. 
Yokohama  Cold  Storage,  located  approximately  20  miles  from 
Yokosuka,  is  the  only  modeled  activity  of  the  NSD  not 
located  within  the  confines  of  Naval  Base  Yokosuka. 

NSD  Yokosuka  has  54  U.  S.  Civil  Service  and  905  Japanese 
National  employees  in  addition  to  the  176  military  personnel 
authorized.  Normal  working  hours  are  0800  to  1645  Monday 
through  Friday  with  a  45  minute  lunch  break.  Non-duty  hour 
processing  of  issue  priority  group  one  (IPG1)  requisitions 
and  IPG2  bearer  walkthrough  and  Casualty  Reporting  System 
(CASREPT)  requisitions  is  handled  by  the  duty  section  on 
weekends  and  by  the  Customer  Services  Division  evening  and 
midnight  shifts  during  the  week.  DPSC  maintains  seven  day  a 
week,  around-the-clock  computer  center  operations  in  support 
of  issue  processing. 

The  Depot  receives  an  average  of  43,000  requisitions  a 
month,  of  which  approximately  90%  are  for  standard  stock 
items.  Of  the  total  demand  for  standard  stock  items,  NSD 
Yokosuka  typically  makes  30,000  issues  per  month  from  its 
$43,000,000  inventory  of  over  78,000  line  items.  75%  of 
those  issues  are  for  material  stored  in  the  general  storage 
locations  of  the  Depot.  The  remaining  25%  are  for  provisions 
stored  in  Yokosuka  Cold  Storage  (Building  1390),  Yokosuka 
Dry  Storage  (B-47)  and  Yokohama  Cold  Storage. 

Figure  3.  2  is  a  basic  flow  diagram  of  NSD  Yokosuka 
issue  operations.  Requisition  input  to  the  system  arrives 
in  two  forms,  hard  copy  or  online.  Online  requisitions  are 
received  via  Automatic  Digital  Network  (AUTODIN),  Disk 
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Oriented  Supply  System  (DOSS)  and  local  customer  remote 
terminal  entry.  The  requirements  of  activities  without 
installed  remote  terminal  entry  equipment  and  all  perishable 
provisions  (9MP/9MB),  ships  store  stock  (  IQ)  and  bearer 
requisitions  are  received  in  hard  copy  form.  Requisitions 
for  9MP,  9MB  and  IQ  material  are  initially  routed  to  the 
Requirements  Division  for  stock  check.  IPG1  requisitions, 
IPG2  bearer  walkthrough,  CASREPT  and  quick  pick  requisitions 
and  all  9MP,  9MB  and  IQ  requisitions  (regardless  of 
priority)  received  by  NSD  are  entered  via  remote  terminal  in 
Customer  Services.  All  other  requisitions  are  transferred  to 
DPSC  for  entry.  Requisitions  are  handled  throughout  the 
Depot  on  a  first  come,  first  served,  within  priority  level 
basis.  Priority  levels,  from  highest  to  lowest,  are  as 
follows: 

1.  IPG1  bearer  walkthrough  all  other  IPG1 

2.  IPG2  bearer  walkthrough 

3.  IPG2  CASREPT  (not  bearer  walkthrough) 

4.  IPG2  quick  pick 

5.  all  other  IPG2 

6.  all  IPG3 

Regardless  of  their  origin,  all  IPG1,  CASREPT,  bearer 
walkthrough,  quick  pick,  dry  provisions  ( 9MF )  and  IQ  requi¬ 
sitions  wait  in  a  queue  file  to  be  processed  by  Uniform 
Automated  Data  Processing  System  (UADPS)  programs  UC02  and 
UC96.  The  queue  file  is  emptied  frequently  (every  5  minutes) 
into  UC02/UC96  for  processing.  Issue  documents  for  material 
determined  to  be  in  stock  are  output  immediately  in  Customer 
Services.  9MP  and  9MB  requisitions  are  entered  under  local 
procedures  and  issue  documents  are  printed  on  the  Customer 
Services  printer.  The  balance  of  IPG2  and  all  IPG3  requisi¬ 
tions  are  processed  in  batch  mode  by  UC02/UC96  and  local 
programs  LC06,  LC07  and  LC08.  Issue  documents  for  material 
determined  to  be  in  stock  are  output  in  Storage  Control. 


Issue  documents  for  provisions  are  output  in  Customer 
Services.  Demand  exceptions  are  reviewed  by  exception  clerks 
in  Customer  Services  and  re-entered  into  the  system. 

All  issue  documents  printed  in  Customer  Services  are 
annotated  or  stamped  as  appropriate  (quick  pick,  CASREPT, 
etc. )  and  are  routed  for  further  processing.  Provisions 
issue  documents  are  delivered  to  the  Storage  Office.  Issue 
documents  produced  for  bearer  walkthrough  requisitions  are 
released  to  the  bearer  to  be  hand  carried  to  the  warehouse 
storing  the  material.  All  other  issue  documents  are  deliv¬ 
ered  to  Storage  Control. 

Storage  Control  personnel  sort  those  issue  documents 
printed  by  the  Storage  Control  printer  and  those  received 
from  Customer  Services  by  warehouse  and  deliver  the  document 
batches  by  bicycle  messenger  to  their  respective  storage 
locations.  Provisions  documents  received  in  the  Storage 
Office  are  also  sorted  by  storage  location.  Issue  documents 
for  provisions  in  Building  1390  and  B-47  are  delivered  by 
the  bicycle  messenger.  Issue  documents  for  perishable  provi¬ 
sions  stocked  in  Yokohama  are  delivered  by  a  truck  that 
leaves  Yokosuka  at  0900  on  workdays,  arriving  in  Yokohama 
later  the  same  morning. 

Upon  receipt  of  issue  documents,  warehouse  personnel 
pick  the  requisitioned  material,  attach  copies  of  the  issue 
document,  and  segregate  it  by  destination.  In  general 
storage  locations,  material  is  staged  separately  for 
delivery  to  the  Publics  Works  Center  (PWC),  the  Ship  Repair 
Facility  (SRF)  and  the  Packing  and  Shipping  Sections  of  the 
Freight  Terminal.  In  provisions  warehouses,  the  majority  of 
material  is  staged  within  the  facility  to  be  delivered 
directly  to  the  requisitioner.  Provisions  issues  for  off- 
base  delivery  or  bearer  pick-up  are  staged  separately.  All 
bearer  issues  are  turned  over  to  the  customer  at  the  ware¬ 
house.  Warehouse  refusals  are  annotated  as  such  on  issue 
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documents  which  are  returned  to  Customer  Services  for 
processing  (i.e.  investigation,  transaction  reversal, 
referal  or  cancellation). 

Material  segregated  for  delivery  in  general  storage 
locations  to  PWC,  SRF,  or  the  Freight  Terminal  is  trans¬ 
ported  by  Labor  and  Equipment  Division  tractor  trains  to  its 
next  destination.  Tractor  trains  run  on  two  separate  routes 
at  0815,  1015,1300  and  1400  on  workdays.  Material  requisi¬ 
tioned  by  PWC  and  SRF  is  delivered  enroute  to  Building  J-39. 
All  material  requiring  packing  prior  to  shipment  is  unloaded 
in  the  Packing  Section  of  J-39.  The  remaining  material  is 
delivered  to  the  Shipping  Section.  Tractor  trains  run  on  an 
as  required  basis  to  deliver  provisions  from  B-47  and 
Building  1390  to  the  Freight  Terminal. 

Material  transported  to  the  Packing  Section  is  packaged 
for  further  transportation  to  the  customer.  Three  basic 
types  of  pack  are  used--light,  parcel  post  or  heavy--as 
appropriate  to  the  material.  When  packing  is  completed  the 
material  is  delivered  to  the  Shipping  Section,  adjacent  to 
the  end  of  the  packing  line,  for  further  processing. 

The  Uniform  Material  Movement  and  Issue  Priority  System 
( UMM IPS)  treats  issues  received  in  the  Shipping  Section  as 
available  for  shipment  to  the  requisitioner  and  issue 
processing  statistics  maintained  by  the  Depot  do  not  record 
handling  time  in  the  Shipping  Section.  Shipping  Section 
operations,  beyond  receipt  of  material,  are  not  modeled  in 
the  simulation  program. 


IV.  HIE  MODEL 


A.  DEFINITION 

The  computer  program  is  written  in  IBM's  GPSS  V.  The 
program  simulates  all  NSD  Yokosuka  functions  that  directly 
support  issue  processing  operations,  from  requisition 
receipt  to  the  point  of  availability  of  the  issue  for  ship¬ 
ment  to  the  requisitioner.  Specific  functions  simulated 
are: 

1.  Requirements  Division  stock  check  of  perishable  provi¬ 
sion  and  ships  store  stock  requisitions. 

2.  Customer  Services  and  DPSC  remote  terminal  entry  of 
hard  copy  requisitions. 

3.  Customer  Services  demand  exception  and  warehouse 

refusal  processing 

4.  Customer  Services  and  Storage  Control  issue  document 
printer  operations 

5.  Storage  Control  and  Storage  Office  sorting  and 
handling  of  issue  documents 

6.  Delivery  of  issue  documents  to  Yokohama  Cold  Storage 
and  Naval  Base  Yokosuka  storage  locations 

7.  Warehouse  pick  and  stage  operations  (and  shipment 
preparations  in  provisions  storage  locations) 

8.  Tractor  train  delivery  of  issues  to  SRF,  PWC  and  the 
packing  and  shipping  sections  of  the  Freight  Terminal 

9.  Packing  operations 

10.  Duty  section  and  late  shift  operations 
A  copy  of  the  program  code  is  provided  as  Appendix  A. 
Listings  of  program  variables,  functions,  transaction  param¬ 
eters  and  storages  referenced  during  the  simulation  are  all 
included  in  the  program  code.  A  GPSS  block  diagram  of  the 
program  structure  is  provided  as  Appendix  B.  The  succeeding 
section  refers  to  segments  of  the  GPSS  block  diagram  to 
relate  the  structure  of  the  simulation  program  to  actual 
Depot  operations. 
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B.  STRUCTURE 


GPSS  simulates  actual  system  performance  by  generating 
requisitions  (referred  to  as  transactions)  at  time  intervals 
modeled  after  real  system  arrivals  and  permitting  the  gener¬ 
ated  transactions  to  proceed  through  block  paths  repre¬ 
senting  real  system  processes.  Each  GPSS  block  executes  a 
subroutine  which  may  delay,  modify,  remove  or  control  the 
flow  of  the  entering  transaction.  In  a  large  system  composed 
of  separate  workcenters,  such  as  NSD  Yokosuka,  transactions 
move  through  a  varied  series  of  processes  before  an  issue 
results.  Although  these  processes  differ  physically,  many 
are  logically  similar  ( e. g. ,  transactions  enter  a  work- 
center,  wait  for  service,  are  processed  and  then  leave  the 
workcenter  for  the  next  processing  step).  Consequently, 
GPSS  is  able  to  simulate  a  wide  variety  of  processes  with  a 
relatively  small  vocabulary  of  blocks. 

GPSS  can  also  generate  control  transactions  in  separate 
modules  to  alter  system  status  ( i. e. ,  control  storage  avail¬ 
ability,  trigger  scheduled  events).  The  generation  of 
control  transactions  and  their  flow  through  the  program 
blocks  is  timed  to  coincide  with  operating  schedules  of  the 
Depot.  Time  is  divided  into  units  of  . 01  hours  in  the  simu¬ 
lation.  The  reader  is  therefore  reminded  to  carefully  inter¬ 
pret  simulation  time  in  the  program  (i.e. ,  30  minutes  is 
represented  as  50,  8  hours  and  45  minutes  as  875,  etc.  ). 

This  section  of  the  chapter  groups  logically  similar 
processes  into  categories  and  references  modules  in  the  GPSS 
block  diagram  in  Appendix  B  to  demonstrate  how  actual 
processes  are  modeled  in  the  program.  All  GPSS  blocks 
discussed  in  this  section  appear  in  upper  case  to  set  them 
apart  from  the  text.  Assumptions  made  in  modeling  the  real 
system  processes  are  presented  as  are  special  programming 
details  that  may  not  be  apparent  to  the  user.  An  under¬ 
standing  of  this  section  will  improve  the  reader's 


comprehension  of  the  program  code.  It  will  also  serve  to 
assist  the  user  in  making  program  changes  for  the  purpose  of 
system  experimentation  or  reflecting  real  system  changes. 


Requisition  generation  and  priority  assignment  is 
modeled  in  the  requisition  generation  module  of  the  program. 
GPSS  V  limits  each  model  to  32,767  concurrently  active 
transactions.  To  remain  within  that  limitation  during  simu¬ 
lation  experiments,  the  number  of  transactions  generated  has 
been  reduced  by  structuring  the  program  to  permit  a  single 
transaction  to  Represent  three  requisitions.  All  succeeding 
program  modules,  with  the  exception  of  the  duty  section 
module,  process  each  transaction  as  if  it  were  3  separate 
requisitions  to  maintain  an  operational  pace  equivalent  to 
actual  Depot  operations. 

The  number  of  demands  generated  in  one  week  of  simu¬ 
lated  time  is  computed  by  multiplying  the  monthly  demand 
level  input  by  the  user  by  a  factor  of  .231  (based  on  an 
average  of  4.33  weeks  per  month).  The  daily  distribution  of 
those  demands  is  determined  by  function  FTHNN  which  is 
derived  from  daily  demand  data  supplied  by  the  NSD.  The 
daily  demand  level  is  then  divided  by  3  to  obtain  the  number 
of  transactions  generated  during  each  simulated  day. 

Daily  requisition  arrival  rates  utilized  in  the 
simulation  are  constant  over  the  weekend,  but  are  computed 
to  force  generation  of  89%  of  weekday  demands  during  normal 
operating  hours,  consistent  with  the  pattern  of  workday 
requisition  arrivals  actually  experienced  by  the  Depot.  As 
data  supporting  an  alternative  distribution  of  requisition 
arrivals  is  not  available  at  this  time,  transactions  are 
allowed  to  proceed  into  the  model  at  a  uniform  rate. 
Although  the  clumping  of  requisition  arrivals  expected 
during  actual  operation  is  not  duplicated,  requisition  flow 
similar  to  that  experienced  by  the  NSD  is  restored  earlv  in 


the  requisition  processing  cycle  by  the  simulation  of  the 
batch  printing  of  issues  documents  in  the  printer  queue 
handling  module. 

The  first  three  requisition  generation  subsections 
of  the  requisition  generation  module  are  responsible  for 
generating  requisitions  on  weekdays--before ,  during  and 
after  normal  operating  hours  respectively.  The  fourth  requi¬ 
sition  generation  subsection  generates  weekend  arrivals.  The 
GENERATE  block  in  each  subsection  creates  a  single  trans¬ 
action  each  simulated  day  at  the  beginning  of  its  assigned 
time  period  (i.e.  ,  0001  for  the  AM  subsection,  0800  for  the 
operating  hours  subsection).  Because  all  of  the  requisition 
generation  subsections  create  a  single  transaction  each  day 
of  the  week,  transactions  generated  in  the  weekday  genera¬ 
tion  subsections  must  be  terminated  on  weekends  and  trans¬ 
actions  generated  in  the  weekend  generation  subsection  must 
be  terminated  on  weekdays.  The  TEST  blocks  permits  the 
generated  transaction  to  proceed  on  workdays  in  the  first 
three  subsections  and  on  weekends  in  the  last  subsection. 
Transactions  failing  that  test  are  transferred  to  the 
TERMINATE  block  labeled  RQTRM  and  removed  from  the  model. 

All  transactions  that  are  not  terminated  continue 
through  the  requisition  generation  subsections.  The  SPLIT 
and  ADVANCE  blocks  combine  to  transform  the  previously 
generated  single  transactions  into  a  uniform  flow  of  trans¬ 
actions  representing  the  arrival  of  requisitions  at  the  NSD. 
Transactions  entering  the  SPLIT  block  are  split  into  the 
number  of  transactions  expected  during  the  period.  The 
ADVANCE  block  then  permits  the  newly  created  transactions  to 
pass  to  the  next  block  at  a  uniform  rate,  where  they  are 
transferred  to  the  ASSIGN  block  PRIAS.  The  ASSIGN  block 
references  function  FONE  and  stochastically  assigns  an 
integer  value  representing  requisition  priority  to  parameter 
1  of  each  transaction.  The  following  PRIORITY  block  copies 


the  parameter  1  value  to  assign  transaction  priorities 
referenced  during  program  execution  to  determine  processing 
order.  All  transactions  are  then  routed  by  their  parameter  1 
value  through  a  path  of  SAVEVALUE  blocks  that  serve  as 
requisition  counters. 

2.  Work  Scheduling 

Operating  schedules  for  Depot  workcenters  during  the 
normal  workday,  the  late  shift  and  duty  section,  the  issue 
document  printers  and  the  tractor  trains  are  all  managed  by 
control  transactions  in  schedule  control  sections.  With  the 
exception  of  normal  workday  scheduling,  which  is  controlled 
in  separate  modules,  all  schedule  control  sections  are 
located  in  the  module  whose  operations  they  control. 

As  an  example  of  how  work  scheduling  is  managed  by 
the  program,  the  schedule  control  section  of  the  duty 
section  module  is  explained  below.  The  first  block  in  the 
section  generates  a  control  transaction  at  the  beginning  of 
each  day.  On  weekdays  the  control  transaction  proceeds 
through  the  module,  alternately  entering  ADVANCE  blocks  to 
simulate  the  passage  of  time  and  UNLINK  blocks  positioned  to 
coordinate  the  flow  of  transactions  with  the  operating 
status  of  the  duty  section.  After  1675  time  units  have 
passed,  marking  the  end  of  the  normal  workday  at  1645,  the 
control  transaction  is  terminated  and  the  process  is 
repeated  at  the  beginning  of  the  next  simulated  day.  On 
weekends  the  control  transaction  is  routed  directly  to  the 
TERMINATE  block  labeled  DTEND  and  removed  from  the  model, 
permitting  the  duty  section  to  remain  in  continuous  opera¬ 
tion  over  the  weekend.  Scheduling  of  the  issue  document 
printer  and  tractor  train  operations  differ  only  in  that 
control  transactions  are  created  at  more  frequent  intervals 
during  the  day  to  trigger  the  repetitively  scheduled 
processes. 
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NSD  workcenters  supporting  issue  processing  opera¬ 
tions  are  represented  throughout  the  program  as  storages.  A 
storage  is  an  entity  provided  by  GPSS  to  simulate  homogenous 
parallel  servers,  that  is,  personnel  working  side  by  side 
performing  similar  duties  at  similar  rates  of  speed.  Each 
storage  referenced  in  the  simulation  is  included  in  the 
storage  definition  section  where  its  symbolic  name,  capacity 
and  description  is  provided.  Storages  that  have  been  thus 
defined  may  then  be  referenced  in  the  program  to  simulate 
the  actual  processing  of  requisitions. 

SKCK  is  the  symbolic  name  of  the  storage  referenced 
by  the  requisition  receipt  module.  It  simulates  the  stock 
check  of  perishable  provision  and  ships  store  stock  requisi¬ 
tions  in  the  Requirements  Division  and  has  a  defined 
capacity  of  two  personnel.  Storage  references  are  commonly 
accompanied  by  two  block  pairs,  QUEUE/DEPART  and 
ENTER/LEAVE.  The  function  of  the  QUEUE  and  DEPART  blocks  is 
to  collect  statistics  regarding  the  time  spent  by  trans¬ 
actions  waiting  for  the  storage  to  become  available  and 
related  queue  data.  The  ENTER  and  LEAVE  blocks  perform  the 
function  of  controlling  access  to  the  ADVANCE  block, 
limiting  its  current  contents  to  the  defined  capacity  of  the 
storage.  After  a  simulation  is  run,  statistics  detailing 
the  time  spent  waiting  for  service  and  the  active  processing 
time  at  each  defined  storage  are  presented.  See  Chapter  V 
for  a  more  detailed  description  of  output  statistics. 

The  time  that  it  takes  to  process  a  single  trans¬ 
action  in  the  Requirements  Division  is  simulated  in  the 
ADVANCE  block  labeled  SKCK.  The  ADVANCE  block  delays  each 
transaction  for  an  explicit  period  of  time  equal  to  the 
value  of  the  variable  V$SKCKS  named  in  the  A  operand.  In 
recognition  of  the  fact  that  each  transaction  represents  3 
requisitions,  the  service  times  used  in  the  model  are 


computed  by  summing  3  individual  service  times.  Individual 
service  times  are  drawn  from  functions  containing  frequency 
distributions  of  service  times  observed  during  actual  opera¬ 
tions  at  NSD  Yokosuka.  The  service  times  of  workcenters  for 
which  frequency  distributions  were  not  available  to  the 
author  are  computed  from  mean  service  times  provided  by  NSD 
and  are  assumed  to  follow  the  negative  exponential  distribu¬ 
tion.  These  included  all  provisions  storage  locations  and 
the  main  warehouse  (F-157).  Mean  service  times  were  also 
used  for  all  Requirements  Division,  Customer  Services 
Division,  Storage  Office  and  Storage  Control  requisition  and 
issue  document  handling  processes  due  to  the  brief  and 
uniform  nature  of  those  functions.  Mean  service  times  were 
not  available  for  packing  operations,  so  Packing  Section 
service  times  employed  in  the  model  were  computed  by 
dividing  the  manhours  recorded  for  each  pack  type  on  the  NSD 
Yokosuka  Uniform  Management  Reports  by  the  number  of  issues 
packed. 

4.  Requisition  Flow  Control 

Most  modules  modeling  workcenter  operations  begin 
with  flow  control  sections  that  serve  two  primary  purposes. 
First,  program  execution  efficiency  is  improved  by  placing 
transactions  that  are  about  to  attempt  entry  into  a  storage 
on  a  "user  chain"  until  the  storage  has  available  capacity. 
Managing  waiting  transactions  in  this  manner  frees  the 
computer  from  continuously  scanning  each  transaction 
attempting  to  enter  a  storage.  Secondly,  the  unlinking  of 
transactions  from  user  chains  at  the  end  of  the  workday 
provides  positive  control  of  high  priority  requisitions  that 
require  transfer  to  the  duty  section  module  for  processing 
after  normal  operating  hours. 

Though  flow  control  sections  in  the  program  differ 
slightly  in  structure,  the  flow  control  section  in  the 
Requirements  Division  module  is  representative  of  the  basic 
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structure  employed  throughout  the  program.  The  first  three 
TEST  blocks  following  SKCKQ  route  transactions  that  have 
joined  the  queue.  Transactions  entering  during  lunch  are 
transferred  to  the  LINK  block  labeled  SKCKL  where  they  are 
placed  on  the  user  chain  SKCKC.  Transactions  entering 
outside  of  the  normal  workday  are  transferred  to  the  TEST 
block  SKCKT  which  routes  transactions  based  on  their 
priority.  High  priority  transactions  ( those  handled  by  the 
duty  section)  are  assigned  a  progress  indicator  in  parameter 
3  that  marks  their  stage  in  processing.  They  are  then 
removed  from  the  QSKCK  queue  and  are  transferred  to  the  duty 
section  module  for  processing.  Low  priority  requisitions 
( those  not  handled  by  the  duty  section)  are  transferred  to 
the  advance  block  labeled  SKCKA  where  they  are  delayed  a 
single  time  unit  to  avoid  an  endless  loop  of  linking  and 
unlinking.  The  transactions  are  then  transferred  to  SKCKL 
and  placed  on  user  chain  SKCKC.  Those  transactions  arriving 
during  normal  operating  hours  proceed  directly  to  the  ENTER 
block  labeled  SKCKE  if  the  ,  storage  SKCK  has  remaining 
capacity.  Otherwise,  the  transactions  are  transferred  to 
SKCKL  and  placed  on  user  chain  SKCKC.  Those  entering  during 
working  hours  when  the  storage  has  no  available  capacity 
proceed  to  the  LINK  block  labeled  SKCKL  where  they  are 
placed  on  user  chain  SKCKC. 

During  normal  operating  hours  one  transaction  is 
unlinked  from  the  user  chain  to  enter  the  storage  for  each 
transaction  leaving  the  storage,  maintaining  full  utiliza¬ 
tion  of  the  storage  as  long  as  transactions  remain  on  the 
user  chain.  All  transactions  are  unlinked  from  user  chain 
SKCKC  at  the  end  of  the  workday  by  a  control  transaction  in 
the  schedule  control  module  so  that  high  priority  trans¬ 
actions  residing  on  the  user  chain  may  be  identified  and 
routed  to  the  duty  section  module.  Low  priority  requisitions 
are  relinked  to  user  chain  SKCKC  to  await  processing  during 
the  next  scheduled  workday. 
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5.  Printer  Operations 

The  NSD  Yokosuka  issue  document  printers  are 
currently  located  in  DPSC  and  Customer  Services.  However, 
the  modeling  of  printer  operations  in  the  program  reflects 
NSD  Yokosuka  plans  to  relocate  the  DPSC  printer  to  Storage 
Control  in  Fiscal  Year  1986. 

Customer  Services  printer  operations  including  the 
schedule  control  section  are  modeled  in  the  printer  queue 
handling  module.  IPG1,  IPG2  (CASREPT,  quick  pick  and  bearer 
walkthrough)  and  all  provisions  transactions  are  routed  to 
the  block  labeled  CSPRQ  and  placed  in  the  QCSPR  queue.  The 
LINK  block  places  all  transactions  on  user  chain  ONE.  The 
transactions  are  released  at  simulated  time  intervals  of  5 
minutes  by  the  UNLINK  block  labeled  UNLNK  in  the  schedule 
control  section,  matching  queue  file  processing  procedures 
followed  by  UC02/UC96.  The  "printed"  transactions  are 
removed  from  the  QCSPR  queue  by  the  DEPART  block.  They 
proceed  through  ENTER  and  LEAVE  blocks  referencing  the  CSPR 
storage  without  an  intervening  advance  block  because  the 
processing  delay  actually  experienced  by  requisitions 
waiting  for  UC96/UC02  to  empty  the  queue  file  :  imulated 
by  the  delay  on  the  user  chain. 

6.  Transportation  Operations 

Issue  processing  functions  of  the  Depot  include  the 
transportation  of  issue  documents  and  material  between 
stationary  workcenters.  The  programming  technique  used  to 
simulate  transportation  processes  involves  linking  trans¬ 
actions  to  user  chains  and  using  control  transactions  gener¬ 
ated  in  corresponding  schedule  control  sections  to  unlink 
them  to  succeeding  modules.  Transportation  processes  that, 
in  actual  operations,  are  essentially  without  maximum  capac¬ 
ities  are  modeled  as  such  ( e. g. ,  the  number  of  issue  docu¬ 
ments  that  may  be  transported  to  Yokohama  Cold  Storage 
during  a  single  delivery  run  is  essentially  unlimited). 
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Modeling  transportation  processes  with  known  capacities  is 
more  complex. 

Operations  of  the  "B"  route  tractor  train  are  simu¬ 
lated  in  the  tractor  train  delivery  module.  Control  trans¬ 
actions  are  created  in  the  schedule  control  section  at 
simulated  times  corresponding  to  the  actual  train  schedule 
and  are  transferred  to  the  UNLINK  block  LOADB  on  workdays. 
The  loading  of  IPG1  and  IPG2  transactions  on  the  tractor 
train  is  managed  by  LOADB  and  the  succeeding  UNLINK  blocks 
in  the  loading  section  which  release  all  transactions  on  the 
JCF‘,  BCH  and  ACH  user  chains  to  the  test  block  BTEST  in  the 
operations  section. 

The  operations  section  controls  transaction  access 
to  the  tractor  trains.  BTEST  permits  IPG1  and  IPG2  trans¬ 
actions  to  proceed  to  the  following  TEST  block.  The  weight 
of  each  transaction  is  then  checked  to  ensure  that  it  does 
not  exceed  the  remaining  capacity  of  the  storage  BTRN. 
Transactions  meeting  that  test  are  transferred  to  BTRNE  to 
enter  the  storage  ( i. e.  are  loaded  on  the  train),  depart 
QBTRN  in  the  following  block  and  are  linked  to  user  chain 
BTRNC  in  the  succeeding  LINK  block.  All  IPG3  transactions 
and  those  transactions  whose  weight  exceeds  the  remaining 
capacity  of  the  storage  (  signifying  that  the  train  has  been 
loaded  to  capacity)  pass  through  the  following  ADVANCE  block 
and  are  transferred  back  to  their  respective  warehouse 
module  to  await  the  next  train.  By  screening  IPG1  and  IPG2 
transactions  in  advance  of  the  normal  loading  cycle,  IPG3 
transactions  at  the  first  tractor  train  stop  are  prevented 
from  effectively  denying  transportation  to  IPG1  and  IPG2 
transactions  at  later  stops.  This  is  consistent  with  tractor 
train  loading  procedures  of  NSD  Yokosuka. 

The  succeeding  blocks  in  the  loading  section  govern 
the  loading  of  IPG3  transactions  returned  to  the  warehouse. 
The  control  transaction  passes  through  an  ADVANCE  block 
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which  delays  it  to  simulate  movement  of  the  tractor  train 
from  J-39  to  its  first  stop,  J  warehouse  area.  The 
following  UNLINK  block  releases,  in  priority  order,  all 
transactions  waiting  on  user  chain  JCH  to  the  TEST  block 
BTRNT.  The  unlinked  transactions  are  then  loaded  on  the 
tractor  train,  capacity  permitting,  in  the  manner  described 
by  the  previous  paragraph.  The  control  transaction  continues 
through  alternating  ADVANCE  and  UNLINK  blocks  to  repeat  this 
process  for  transactions  waiting  at  warehouse  areas  A  and  B. 

After  linking  waiting  transactions  to  the  user  chain 
BTRNC,  the  control  transaction  in  the  loading  section  enters 
an  ADVANCE  block  which  delays  it  to  simulate  movement  of  the 
train  to  the  first  unloading  points,  PWC  and  SRF.  When  the 
control  transaction  enters  the  succeeding  UNLINK  block,  all 
transactions  on  the  user  chain  BTRNC  leave  the  storage  BTRN 
and  proceed  to  the  TEST  block  TMTST.  Transactions  with  a 
parameter  4  value  indicating  delivery  to  PWC  and  SRF  are 
transferred  for  termination  simulating  delivery  to  requisi- 
tioner.  All  other  transactions  are  delayed  by  an  ADVANCE 
block  to  simulate  transportation  to  the  Freight  Terminal. 

7.  Duty  Section  Operations 

The  flow  control  sections  throughout  the  program  are 
designed  to  forward  IPG1  and  IPG2  CASREPT  and  bearer 
walkthrough  transactions  to  the  duty  section  module  at  the 
end  of  the  workday  and  on  weekends.  Processing  steps  in  the 
duty  section  module  are  similar  to  normal  workday  procedures 
except  that  all  transactions  are  stock  checked  before  remote 
terminal  entry  and  transportation  delays  are  modeled  to 
recognize  the  fact  that  requisitions  handled  by  the  duty 
section  are  processed  continuously  from  receipt  to  issue. 
Additionally,  all  9MP  and  9MB  issues  are  made  from  Building 
1390,  as  nearly  all  after  hours  provisions  issues  made  by 
NSD  Yokosuka  are  for  requisitions  received  from  inport 
ships. 
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So  that  transportation  delays  due  to  single  issue 
processing  by  the  duty  section  are  accurately  modeled,  each 
transaction  (representing  three  requisitions  at  this  point) 
entering  the  storage  DUTY  is  split  into  three  identical 
transactions,  each  representing  a  single  requisition.  The 
number  of  transactions  that  may  be  simultaneously  processed 
in  the  duty  section  module  is  limited  to  the  duty  section 
storage  capacity  of  2  which  is  consistent  with  the  number  of 
personnel  actually  available  in  the  late  shifts  and  duty 
section  to  handle  issues. 

The  storage  DUTY  is  unique  in  that  it  has  several 
ADVANCE  blocks  between  the  ENTER  and  LEAVE  blocks,  each 
representing  a  step  in  actual  issue  processing.  The  first 
block  in  the  operations  section  joins  all  transactions  to 
the  queue  DUTYQ.  The  succeeding  TEST  blocks  send  entering 
transactions  directly  to  the  block  labeled  DUTYS  if  the 
storage  DUTY  has  available  capacity.  Those  entering  before 
1646  on  workdays  or  when  the  storage  is  full  are  linked  to 
the  user  chain  DUTYC  to  await  processing. 

Transactions  transferred  directly,  as  well  as  those 
unlinked  from  user  chain  DUTYC  for  processing,  proceed  to 
the  SPLIT  block  labeled  DUTYS.  There,  each  transaction  is 
split  into  3  separate  transactions,  each  representing  a 
single  requisition  as  previously  explained.  The  following 
TRANSFER  block  sends  the  original  transaction  directly  to 
the  ENTER  block  DUTYE.  The  newly  created  transactions  are 
first  transferred  to  QSPLT  to  be  joined  to  DUTYQ  before 
proceeding  to  the  ENTER  block.  Transactions  proceed  beyond 
the  ENTER  block  as  the  defined  capacity  of  DUTY  permits. 
They  are  removed  from  DUTYQ  in  the  next  block  and  then 
transferred  to  the  starting  point  in  the  duty  section  module 
appropriate  to  the  progress  indicator  stored  in  parameter  3. 

The  complete  processing  of  each  transaction  is  then 
simulated  as  the  transaction  passes  through  the  remainder  of 


the  module  blocks.  When  processing  is  completed,  each  trans¬ 
action  passes  through  the  dummy  ADVANCE  block  labeled  DUTTR, 
placed  to  provide  a  count  of  leaving  transactions  that  is 
referenced  by  the  following  TEST  block.  The  TEST  block 
allows  every  third  transaction  to  pass  through  the  next 
block  which  unlinks  a  single  transaction  ( representing  3 
requisitions)  to  DUTYS.  The  above  process  is  then  repeated 
for  the  unlinked  transaction. 

The  TRANSFER  block  SEND  transfers  transactions  that 
complete  processing  in  the  duty  section  module  to  termina¬ 
tion  blocks  appropriate  to  each  transaction.  At  the  start  of 
the  following  workday,  any  unprocessed  transactions 
remaining  on  the  user  chain  DUTYC  are  unlinked  to  DUTYD  by  a 
control  transaction  in  the  schedule  section.  Those  trans¬ 
actions  are  removed  from  DUTYQ  and  transferred  back  to  their 
point  of  origin  indicated  by  parameter  3.  The  processing  of 
all  transactions  that  have  been  split  into  individual  requi¬ 
sitions  is  completed  in  the  duty  section  module. 


A.  INTRODUCTION 


This  chapter  will  review  verification  of  the  program 
structure  and  discuss  procedures  to  be  used  in  the  valida¬ 
tion  of  simulation  results.  Verification  and  validation  are 
terms  used  to  describe  the  process  of  establishing  the  cred¬ 
ibility  of  simulation  models.  The  verification  process 

entails  ensuring  that  the  logic  of  the  computer  program 
corresponds  to  that  of  the  real  system.  Validation  takes  the 
process  a  step  further,,  by  testing  the  model  to  determine  if 
it  reasonably  reflects  real  system  processes. 

Program  output  used  during  verification  and  validation 
is  produced  at  the  end  of  the  simulation.  The  output  is 
divided  into  4  "snapshots"  presenting  a  set  of  cumulative 
statistics  at  the  end  of  each  simulated  week.  The  final 
snapshot  of  the  program  output  used  to  verify  this  model  is 
provided  as  Appendix  C.  The  sections  listed  below  are  of 
particular  interest: 

1.  Queue  statistics 

2.  Storage  statistics 

3.  Savevalues--total  requisition  generation  count 
(REQCT),  requisition  Generation  count  by  issue 
priority  group  (PRONE,  PRlWO  and  PRTHR),  NIS  reauisi- 
tion  count  (NISCT),  warehouse  refusal  count  (WRCT)  and 
tractor  train  run  count  ( ANUM,  BNUM  and  PNUM) 

4.  Tables--throughput  time  distribution  for  all  issues 
(ALL)  and  throughput  time  distribution  for  issues  by 
issue  priority  group  ( IPGON,  IPGTW,  IPGTH) 

5.  Block  counts 

Storage  statistics  provide  information  regarding  the 
active  processing  time  experienced  by  transactions  ( requisi¬ 
tions)  during  the  simulation  as  well  storage  (workcenter) 
utilization  information.  For  each  storage  defined  in  the 
model,  GPSS  provides  standard  output  that  can  be  used  to 
study  system  performance.  Storage  names  and  capacities  are 


provided  under  the  corresponding  headings.  The  total  number 
of  transactions  processed  during  the  simulation  may  be  found 
in  the  column  labeled  "ENTRIES. "  The  average  processing  time 
for  those  transactions  that  have  been  processed  should 
closely  approximate  the  mean  of  the  service  time  data 
supplied  to  the  program  and  may  be  verified  by  examining 
data  in  the  column  headed  "AVERAGE  TIME/UNIT".  Statistics 
measuring  storage  utilization  during  operating  hours  are  of 
particular  interest  to  the  user.  The  percentage  of  time  that 
a  storage  is  available  for  normal  operations  is  given  in  the 
column  "PERCENT  AVAILABILITY"  (e.g.  ,  the  storage  SKCK  avail¬ 
able  23.  8%  of  the  time  or  .  238  X  168  hours  =  40  hours  per 
week).  During  this  period  of  availability,  average  utiliza¬ 
tion  may  be  found  under  the  "AVAIL.  TINE"  heading.  For  the 
storage  SKCK,  this  value  was  .  135  or  13. 5% 

Queue  statistics  detail  the  waiting  times  experienced  by 
transactions  attempting  to  enter  storages  in  the  model. 
They  are  provided  immediately  following  storage  statistics 
in  a  similar  format.  The  maximum,  average  and  total  number 
of  requisitions  awaiting  processing  in  each  of  the  queues 
listed  in  the  first  column  are  provided  in  the  next  three 
columns.  The  column  headed  "AVERAGE  TIME/TRANS"  provides 
the  average  time  spent  waiting  for  processing  by  all  trans¬ 
actions  joining  the  queue.  This  information  is  used  to 
isolate  delays  in  transaction  processing  and  is  particularly 
useful  during  experimentation  in  identifying  system 
"bottlenecks.  " 

Savevalues  are  employed  as  "counters"  during  the  simula¬ 
tion.  Savevalues  tally  the  total  number  of  transactions 
entering  the  system  and  provide  subtotals  by  issue  priority 
groups.  They  are  also  used  to  count  NIS  and  warehouse 
refusal  transactions  experienced  during  the  simulation. 
During  validation,  the  output  values  for  savevalues  defined 
in  the  program  may  be  compared  to  input  parameters  to  verify 


the  demand  level  and  mix,  acting  as  a  yardstick  for  evalu¬ 
ating  system  performance. 

Tables  defined  in  the  program  are  designed  to  provide 
system  throughput  data  that  may  be  compared  to  Uniform 
Material  Movement  and  Issue  Priority  System  (UMMIPS)  statis¬ 
tics  maintained  by  the  Depot.  Tabulate  blocks  are  posi¬ 
tioned  in  the  termination  module  to  collect  statistics  at 
the  point  of  issue  or  availability  for  shipment.  The  system 
entry  time  of  each  transaction  entering  a  TABULATE  block  is 
subtracted  from  the  current  simulation  clock  time,  recording 
the  difference  as  the  total  issue  processing  time.  The 
elapsed  processing  times  of  all  transactions  representing 
issues  are  aggregated  and  presented  as  a  frequency  distribu¬ 
tion  table. 

The  first  row  of  data  in  each  table  presents  the  total 
number  of  transactions  tabulated,  the  mean  throughput  time 
and  the  standard  deviation.  In  the  body  of  the  frequency 
distribution  table,  the  data  is  grouped  into  predefined 
intervals  whose  upper  limits  are  listed  in  the  first  column. 
Because  simulated  time  in  the  model  is  based  on  units  of  . 01 
hours,  the  listed  upper  limits  must  be  divided  by  100  to 
obtain  the  correct  time  in  hours.  The  frequency  of  occur¬ 
rence,  percentage  of  total  occurrences  and  cumulative 
percentage  of  occurrences  in  each  interval  are  presented  in 
the  next  three  columns.  As  in  the  savevalue  output  section, 
one  table  is  used  to  tabulate  all  transactions  leaving  the 
system  and  three  separate  tables  present  tabulations  for  the 
three  issue  priority  groups. 

While  the  block  count  section  of  the  program  does  not 
provide  useful  information  during  the  validation  phase,  it 
is  a  valuable  tool  during  verification  to  review  transaction 
flow.  A  current  and  total  transaction  count  is  provided  for 
each  block  in  the  program.  This  data  can  be  compared  to 
corresponding  block  operands,  especially  flow  control  blocks 


like  TEST  or  TRANSFER,  to  ensure  that  program  logic  is 
consistent  with  real  system  operations. 

B.  VERIFICATION 

Steps  in  the  verification  phase  are  designed  to  expose 
coding  and  logic  errors.  Transaction  generation  and  flow  are 
reviewed  using  block  count  and  savevalue  statistics  to 
verify  that  the  characteristics  of  requisition  flow  at  NSD 
Yokosuka  is  duplicated  by  the  simulation  model.  The  verifi¬ 
cation  phase  was  completed  using  the  final  snapshot  in  the 
output  listing  provided  by  Appendix  C. 

The  savevalue  REQCT  counted  39,780  transactions  entering 
the  model  during  the  four  weeks  of  simulated  operations 
conducted  at  a  monthly  demand  level  of  43,00  requisitions. 
Assuming  4.33  weeks  to  the  month,  the  entry  of  39,692  trans¬ 
actions  ((43,000/4.33)  X  4  weeks)  would  have  been  expected. 
The  difference  between  the  requisition  receipt  rate  experi¬ 
enced  from  that  expected  is  due  to  truncation  during  GPSS 
variable  computation  and  may  be  compensated  for  by  slightly 
increasing  the  demand  level. 

The  characteristics  of  transactions  entering  the  system 
were  also  reviewed.  Block  counts  of  the  SPLIT  blocks  in  the 
workday  requisition  generation  subsections  were  used  to 
compute  the  percentage  of  transactions  entering  during  the 
normal  operating  hours  of  the  workday.  89%  of  all  workday 
transactions  entered  the  model  during  the  simulated  time 
period  of  0800  -  1645,  matching  the  pattern  of  real  system 
arrivals.  Priority  assignment  recorded  by  the  savevalues 
PRION,  PRITW  and  PRITH  were  compared  to  the  priority  assign¬ 
ment  input  data  in  function  FONE.  The  recorded  number  of 
transactions  in  each  priority  group  matched  expected 
results. 

Requisition  flow  points  representing  the  routing  of 
online  requisitions,  perishable  provisions  requisitions 
stock  checked  in  Requirements  Division,  demand  exceptions. 
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NIS  requisitions  and  warehouse  refusals  were  all  verified  by 
reviewing  block  count  statistics.  All  observed  counts 
differed  from  expected  values  by  less  than  1%  with  the 
exception  of  the  warehouse  refusal  count.  The  difference  in 
warehouse  refusals  observed  from  the  number  expected  was  4% 
and  is  attributed  to  the  smaller  sample  size  of  67  warehouse 
refusals. 

Warehouse  location  assignment  in  the  model  is  handled  by 
the  ASSIGN  block  labeled  LOCAS  in  the  warehouse  assignment 
module.  A  temporary  TABULATE  block  was  inserted  following 
LOCAS  to  determine  and  verify  the  assignments  to  each  ware¬ 
house  area.  Observed  differences  from  expected  assignments 
ranged  from  . 01%  to  13%.  Fluctuations  in  warehouse  arrivals 
of  this  magnitude  are  exceeded  by  those  experienced  in 
normal  Depot  operations  and  do  not  result  in  appreciable 
differences  in  simulation  results. 

C.  VALIDATION 

Service  time  observation  data  necessary  to  validate  this 
model  is  not  available  to  the  author.  Before  validation  of 
the  model  can  begin,  frequency  distributions  of  observed 
service  times  in  F-157,  all  provisions  storage  locations  and 
the  packing  section  must  be  completed  and  entered  as  func¬ 
tions  in  the  model.  After  all  of  the  data  distributions  are 
established  and  verified  in  the  models,  the  following  vali¬ 
dation  procedure  should  be  us°d. 

In  the  validation  phase,  the  credibility  of  the  model  is 
established  by  developing  a  set  of  actual  performance 
statistics  to  compare  to  queue  storage  and  table  statistics 
produced  by  the  program.  Depot  performance  statistics  from  a 
period  of  at  least  one  month  of  normal  operating  tempo 
should  be  collected  to  provide  both  the  demand  level  to  be 
simulated  and  the  real  system  performance  data  used  to  judge 
model  performance. 
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The  first  step  in  validation  should  be  to  review  overall 
system  performance.  Problems  observed  in  this  step  will  j 

serve  as  starting  points  in  the  identification  of  module-  j 

level  problems.  Statistics  reported  by  NSD  in  the  Issue 
Processing  Analysis  Section  of  the  Supply  Distribution  and 

i 

Inventory  Control  Report  ( NAVSUP  1144)  should  be  compared  to  ! 

the  IPGON,  IPGTW  and  IPGTH  tables  in  the  output  section  of 

the  program.  More  specifically,  for  each  issue  priority 
group,  the  cumulative  percentage  figure  for  the  interval 
with  the  upper  limit  matching  the  corresponding  UMMIPS 
processing  time  standard  (one,  two  and  eight  days  respec¬ 
tively)  should  be  compared  to  the  percent  shipped  on  time 
figure  reported  on  the  NAVSUP  1144.  Three  different  basic 
observations  may  be  made  at  this  point. 

1.  Simulation  throughput  time  statistics  closely  approxi¬ 
mates  real  system  performance 

2.  Simulation  throughput  time  statistics  differ  from  real 
system  performance  uniformly  across  issue  priority 
groups. 

3.  Simulation  throughput  time  statistics  differ  from  real 
system  performance  inconsistently  across  issue 
priority  groups. 

In  the  case  of  the  first  observation,  remaining  validation 
steps  can  be  limited  to  a  review  of  queue  and  storage 
program  output  sections.  Observation  of  either  of  the  other 
two  results  may  require  a  detailed  analysis  of  the  input 
data  used  by  the  model  (i.e. ,  service  times,  storage  capaci¬ 
ties)  and  the  program  logic  representing  decision  rules 
employed  by  NSD  personnel. 

If  transaction  throughput  times  by  issue  priority  groups 
differ  uniformly  from  real  system  performance,  queue  and 
storage  data  should  be  compared  to  corresponding  workcenter 
workloads.  For  example,  if  simulated  throughput  times  were 
uniformly  slower  than  real  system  operation,  queue  "AVERAGE 
CONTENTS"  and  "AVERAGE  TIME/TRANS"  data  should  be  examined. 

Queues  reflecting  high  average  contents  and  reporting  long 
average  time  per  transaction  values  relative  to  other  queues 
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should  be  reviewed  first.  Conversely,  storages  reporting 
high  "UTILIZATION  DURING  AVAIL.  TIME"  should  be  examined 
before  storages  reporting  low  utilization.  Real  system  work- 
center  backlogs,  utilization  rates  and  throughput  should  be 
compared  to  data  from  the  suspect  queues  and  storages. 
Discrepancies  identified  between  actual  workcenter  perform¬ 
ance  and  corresponding  queue  and  storage  statistics  will 
most  likely  result  from  understated  capacities,  overstated 
or  poorly  defined  service  times,  or  both. 

When  deviation  from  real  system  performance  does  not 
occur  uniformly  across  issue  priority  groups,  program  logic 
based  on  decision  rules  provided  by  NSD  Yokosuka  may  not 
accurately  reflect  actual  operations.  For  example,  if  simu¬ 
lated  throughput  times  for  IPG1  transactions  were  signifi¬ 
cantly  faster  than  real  system  performance,  while  IPG2  and 
IPG3  performance  was  substantially  as  expected,  handling  of 
IPG1  requisitions  in  the  program  should  be  reviewed.  Code 
segments  modeling  UC02/UC96  queue  files  and  special  delivery 
of  IPG1  issue  documents  missing  normal  delivery  runs  should 
be  compared  to  real  system  decision  rules.  If  this  review 
fails  to  produce  an  explanation  for  the  discrepancy,  inter¬ 
mediate  MARK  and  TABULATE  blocks  should  be  inserted  to 
measure  throughput  time  in  smaller  segments  of  the  program 
by  issue  priority  groups  in  an  effort  to  localize  the 
problem. 

The  validation  procedures  discussed  above  are  by  no 
means  all  inclusive,  however,  they  should  serve  as  a  guide 
to  the  validation  process.  Simulation  model  validation  is 
an  iterative  process.  After  identified  problems  have  been 
corrected,  the  program  should  be  run  and  the  results 
compared  again  against  real  system  performance  data.  When 
validation  is  completed,  input  parameters  and  output  statis¬ 
tics  should  be  retained  as  a  baseline  for  model 


experimentation. 


One  major  purpose  of  simulation  is  to  perform  experimen¬ 
tation  that  will  provide  predictive  information  regarding 
real  system  performance  under  controlled  changes  to  the 
system  and  its  conditions.  Simulation  experiments  reviewed 
in  this  chapter  were  conducted  for  the  purpose  of  demon¬ 
strating  experimentation  techniques.  The  baseline  program 
used  during  experimentation  models  NSD  issue  processing 
operations  under  a  normal  load  of  43,000  requisitions  a 
month  and  is  identical  to  the  program  listing  provided  as 
Appendix  A.  The  baseline  program  output  referenced  is  the 
program  output  included  as  Appendix  C.  As  the  baseline 
program  has  not  been  validated,  it  should  be  emphasized  that 
the  results  of  this  series  of  simulation  experiments  are 
useful  for  illustrative  purposes  only. 

Consider  the  following  demonstration  of  experimentation 
procedures.  NSD  Yokosuka  Planning  Division  analysts  have 
estimated  that  the  support  of  an  additional  Carrier  Battle 
Group  (CBG)  under  peacetime  conditions  would  result  in  a  70% 
increase  in  requisitions  received.  The  objective  of  this 
series  of  experiments  was  to  observe  simulated  issue 
processing  operations  of  NSD  Yokosuka  for  a  period  of  four 
weeks  under  those  conditions.  The  information  obtained  from 
the  experimental  models  could  be  used  to  estimate  the  addi¬ 
tional  resources  the  Depot  might  require  to  continue 
providing  approximately  the  same  level  of  support. 

The  experimentation  plan  calls  for  an  initial  run  to 
simulate  NSD  operations  at  a  monthly  demand  level  of  73,100 
requisitions  to  identify  processing  bottlenecks  in  the 
system.  After  evaluation  of  the  initial  run  is  completed, 
adjustments  to  the  model  will  be  made  reflecting  options 
that  would  be  available  to  the  Depot  during  actual  operation 


(i.e.  ,  additional  personnel,  shift  changes,  scheduling  of 
additional  tractor  train  runs. )  After  modifications  to  the 
model  are  completed,  the  simulation  run  will  be  repeated. 
The  results  of  the  second  simulation  will  then  be  evaluated 
and  the  process  will  continue  in  an  iterative  manner  until  a 
satisfactory  solution  is  obtained.  This  plan  was  executed 
and  the  results  are  explained  below. 

The  throughput  time  tables,  storage  and  queue  statistics 
produced  by  the  first  experiment  were  compared  to  Appendix 
C.  The  percentage  of  issues,  by  issue  priority  group,  made 
within  UMMIPS  time  standards  with  UMMIPS  performance  statis¬ 
tics  recorded  during  normal  operating  levels  did  not  indi¬ 
cate  a  serious  problem  at  first  glance.  IPG1  and  IPG2 
UMMIPS  performance  remained  essential  unchanged.  The 
percentage  of  IPG3  issues  made  within  the  UMMIPS  time  stan¬ 
dard  of  seven  days  (16,800  simulation  time  units)  fell  from 
99. 1%  under  normal  conditions  to  95. 3%.  The  first  indication 
of  a  problem  was  in  the  actual  number  of  IPG3  issues.  The 
18,693  IPG3  issues  recorded  reflected  an  increase  of  only  9% 
over  the  17,157  IPG3  issues  made  during  the  baseline  experi¬ 
ment,  though  the  number  of  requisitions  received  increased 
by  70%.  A  review  of  queue  statistics  explained  the  modest 
increase  in  IPG3  issues.  Snapshot  queue  statistics 
confirmed  that  warehouse  area  A,  the  main  warehouse,  the  B 
route  tractor  train  and  packing  queues  steadily  increased  in 
length  indicating  that  arrival  rates  in  those  areas  exceeded 
the  service  rates.  This  was  confirmed  by  utilization  rates 
in  the  corresponding  storages  approaching  or  equaling  100%. 
The  Savevalue  count  BNUM  (the  B  route  tractor  train  count) 
underscored  the  issue  transportation  problem.  The  B  route 
required  97  runs  to  transport  issues  from  warehouse  areas  A, 
B,  and  J,  exceeding  the  scheduled  80  runs  by  21%. 

Based  on  these  changes  in  system  performance  due  to  the 
increase  in  load  conditions,  the  "system"  was  modified  in 
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the  following  manner.  Since  processing  bottlenecks  were 
localized  in  relatively  few  workcenters,  spot  adjustments, 
as  opposed  to  blanket  shift  changes,  were  made  to  compensate 
for  the  additional  workload.  The  warehouse  area  A  and  main 
warehouse  storage  capacities  were  increased  from  2  to  3  and 
from  8  to  11,  respectively.  Each  modification  required  a 
change  to  the  capacity  listed  in  the  storage  definition 
block  and  to  the  number  of  transactions  unlinked  in  the  user 
chain  control  module.  The  number  of  heavy  pack  crews  was 
increased  from  3  to  4  and  the  number  of  personnel  in  the 
light  pack  line  was  increased  from  5  to  7  by  changes  to  the 
program  code  similar  to  those  made  to  the  warehouse  stor¬ 
ages.  Additional  tractor  train  runs  on  the  B  route  were 
scheduled  at  1500  and  1700  each  workday.  A  single  additional 
run  was  scheduled  on  the  A  route  to  handle  the  anticipated 
increase  in  issues  from  the  main  warehouse.  The  changes  were 
implemented  by  duplicating  code  from  an  earlier  train  run, 
changing  only  the  control  transaction  generation  time.  The 
management  discretion  train  routes  previously  scheduled  for 
1500  were  rescheduled  to  1800  by  changing  the  control  trans¬ 
action  generation  times. 

After  the  changes  were  completed,  the  second  simulation 
experiment  was  run.  The  number  of  IPG1  and  IPG2  issues  and 
their  UMMIPS  performance  statistics  remained  stable  in  the 
second  run.  IPG3  issues  increased  from  18,693  to  26,403,  an 
increase  of  41%  over  the  previous  experiment  and  54%  over 
the  baseline  issues.  The  percentage  of  IPG3  issues  made 
within  UMMIPS  time  standards  increased  to  97. 1%.  The  storage 
and  queue  statistics  of  warehouse  area  A  and  the  main  ware¬ 
house  were  returned  to  acceptable  levels  by  the  capacity 
increases.  The  A  route  tractor  train  queue  lengths  recorded 
in  the  snapshot  statistics  produced  during  the  second  exper¬ 
iment  increased  only  slightly,  indicating  that  the  single 
additional  run  scheduled  was  sufficient  to  handle  the 
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increase  in  main  warehouse  issues  that  had  been  anticipated. 
The  B  route  tractor  train  queue  lengths  showed  significant 
improvement,  however,  the  average  transaction  queue  waiting 
time  was  an  unacceptable  117  hours.  Packing  Section  utiliza¬ 
tion  remained  at  100%  with  the  increase  in  storage  capacity 
partially  offset  by  the  increase  in  issues  transported  by 
the  additional  tractor  train  runs. 

The  results  of  the  second  run  indicated  that  changes  to 
the  system  were  still  required  in  the  issue  transportation 
and  packing  sections.  In  the  third  experiment,  additional 
tractor  train  runs  on  the  B  route  were  scheduled  at  0925  and 
1125  on  workdays  to  reduce  the  delay  experienced  by  trans¬ 
actions  waiting  for  transportation  on  the  B  route  tractor 
train.  The  capacity  of  the  heavy  pack  storage  was  increased 
from  4  to  5  and  the  light  pack  storage  from  7  to  9.  The 
simulation  was  repeated  and  results  of  third  simulation 
experiment  were  examined.  IPG1  and  IPG2  statistics  remained 
stable.  The  number  of  IPG3  issues  rose  to  28,683  with  97.8% 
of  all  issues  made  within  UMMIPS  time  standards.  All  storage 
utilization  rates  had  fallen  sufficiently  below  100%  to 
eliminate  the  exploding  queue  characteristics  observed  in 
the  previous  experiments. 

Experimentation  could  be  continued  to  restore  IPG3 
UMMIPS  performance  standards  observed  in  the  baseline  simu¬ 
lation  by  following  the  same  procedures  employed  in  the 
first  three  experiments.  As  observed  during  this  series  of 
experiments,  obtaining  the  desired  results  is  an  iterative 
process.  Modifications  made  to  the  model  depend  on  the 
observed  conditions  unique  to  each  experiment  and  are  easily 
made  by  personnel  with  only  a  limited  background  in  simula¬ 
tion  techniques  and  GPSS. 
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A.  CONCLUSIONS 

1.  Discrete  Event  Simulation  Using  GPSS  Y 

Simulation  using  GPSS  V  can  be  an  effective 

predictive  tool  for  NSD  Yokosuka  planning  personnel.  The  NSD 
is  composed  of  interrelated  queueing  systems  that  may  be 
accurately  modeled  by  discrete  event  simulation  techniques. 
The  system  throughput,  resource  utilization  and  queue 
statistics  produced  by  GPSS  V  during  simulation  experimenta¬ 
tion  are  well  suited  to  the  information  requirements  of 
logistics  planners.  Making  program  changes  during  system 
experimentation  is  a  relatively  simple  process,  well  within 
the  capability  of  personnel  with  only  an  introduction  to 
GPSS. 

2.  Discrete  Event  Simulation  Using  GPSS /PC 

NSD  Yokosuka  issue  processing  operations  could  not 
be  modeled  with  Minuteman  Software's  GPSS/PC  because  of  the 
substantial  memory  requirements  of  the  model.  Manufacturer 
suggestions  that  GPSS/PC  will  handle  2000  concurrently 
active  transactions  indicates  that  input  stream  compression 
on  the  order  of  20  requisitions  to  each  transaction  will  be 
necessary  to  keep  memory  requirements  within  the  640  kilo¬ 
bytes  permitted  by  DOS. 

B.  RECOMMENDATIONS 

1.  Data  Collection 

The  data  collection  efforts  of  NSD  Yokosuka  should 
be  completed  to  permit  model  validation  and  experimentation 
using  the  present  GPSS  V  program.  The  use  of  existing  mean 
times  to  model  requisition  and  issue  document  handling 
processes  (  i.  e.  ,  remote  terminal  entry,  document  sorting) 
should  not  have  an  adverse  impact  on  model  performance  due 


to  the  brief  and  uniform  nature  of  the  tasks.  However,  the 
greater  length  and  variability  of  service  times  in  warehouse 
locations  and  the  Packing  Section  do  not  permit  accurate 
modeling  with  estimated  mean  times.  The  construction  of 
frequency  distributions  from  random  samples  of  actual 
service  times  in  the  provisions  storage  locations,  F-157  and 
the  Packing  Section  will  be  necessary  to  complete  model 
validation. 

2.  Model  Experimentation 

If  data  collection  and  model  validation  efforts  can 
be  completed  under  the  coordination  of  NSD  Yokosuka,  the 
cooperation  of  an  activity  equipped  with  an  IBM  mainframe 
computer  operating  under  the  VM/CMS  operating  system  will  be 
necessary  to  permit  experimentation  with  the  model.  Other 
activities  in  Japan,  the  Naval  Postgraduate  School  and  the 
Navy  Fleet  Material  Support  Office  all  offer  support 
possibilities. 

3.  Microcomputer  Implementation  of  the  Model 

Eventual  implementation  of  a  microcomputer  version 

of  the  model  would  permit  NSD  Yokosuka  Planning  Division 
analysts  to  experiment  with  the  model  interactively.  If 
validation  of  the  present  model  is  completed,  it  should  be 
converted  to  GPSS/PC  and  the  modifications  necessary  to 
compress  the  input  stream  should  be  made.  Validation  of  the 
GPSS/PC  version  should  then  be  completed  in  the  same  manner 
as  the  original  model. 
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//YOKO  JOB  (4939,9999) , 'MIKE  CLIFT1 ,CLASS=G 
//*MAIN  LINES=(40) 

//  EXEC  GPSSV, REGION. GO=2048K 
//SYSIN  DD  * 

REALLOCATE  XAC, 20000 
REALLOCATE  FAC,0 
REALLOCATE  LOG,0 
REALLOCATE  TAB, 10 
REALLOCATE  FSV,15 
REALLOCATE  HSV,0 
REALLOCATE  BSV,0 
REALLOCATE  LSV,0 
REALLOCATE  GRP,0 
REALLOCATE  FMS , 0 
REALLOCATE  HMS , 0 
REALLOCATE  BMS,0 
REALLOCATE  LMS , 0 
REALLOCATE  STO,100 
REALLOCATE  QUE,100 
REALLOCATE  COM. 500000 

*  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  x  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  * 

**  PROGRAM  EXECUTION  CONTROL  ** 

**  THE  SIMULATE  STATEMENT  MUST  FOLLOW  ALL  JCL  STATEMENTS  AND  GPSS  ** 
**  REALLOCATE  STATEMENTS.  IT  MARKS  THE  BEGINNING  OF  THE  EXECUTABLE  ** 
**  PROGRAM.  THE  PRECEDING  REALLOCATE  STATEMENTS  ARE  USED  TO  ALLOCATE** 
**  ADDRESSABLE  MEMORY  AMONG  VARIOUS  ENTITIES  DEFINED  IN  THE  PROGRAM.** 
**************************************************  ******************** 

* 


SIMULATE 


BEGIN  SIMULATION 


********************************************************************** 
**  INPUT  PARAMETERS  ** 

**  INPUT  PARAMETER  VARIABLES  ARE  ASSIGNED  VALUES  FROM  DATA  PROVIDED  ** 
**  BY  NSD .  INPUT  PARAMETER  VARIABLES  ARE  USED  TO  CONTROL  THE  NUMBER  ** 
**  AND  TYPE  OF  TRANSACTIONS  GENERATED  IN  THE  SIMULATION.  THEY  MAY  ** 
**  BE  CHANGED  FOR  THE  PURPOSE  OF  EXPERIMENTATION.  ** 

it 

**DEMAND  LEVEL  INPUT  PARAMETER**************************************** 

* 

**TOTAL  DEMANDS  PER  MONTH** 

DMAND  VARIABLE  43000 

k 

**INPUT  PARAMETERS  EXPRESSED  IN  NUMBER  PER  1000  REQS  REC ' D************ 

**GROSS  AVAILABILITY** 

GROSS  VARIABLE  651 

* 

**REQUISITIONS  RECEIVED  VIA  AUTODIN,  DOSS  OR  LOCAL  CUSTOMER  RTE** 

ONLIN  VARIABLE  447 

k 

**NO  OF  WEEKDAY  DEMANDS  REC 1 D  DURING  WORKDAY** 

DAYDD  VARIABLE  891 

k 

**DEMAND  EXCEPTIONS** 

DMDEX  VARIABLE  63 

j k 

**PERISHABLE  PROVISIONS  REQS  -  9MP/9MB** 

PERPV  VARIABLE  177 

k 

**DRY  PROVISIONS  REQS  -  9MF** 

DRYPV  VARIABLE  67 

k 

**SHIPS  STORE  STOCK  REQS  -  IQ** 

SSS  VARIABLE  13 

k 

****INPUT  PARAMETERS  EXPRESSED  IN  NUMBER  PER  1000  ISSUES*************** 

k 


**WAREHOUSE  REFUSALS** 

WHREF  VARIABLE  3 

* 

**INPUT  PARAMETERS  EXPRESSED  IN  AVERAGE  WEIGHT  IN  LBS  OF  THREE  ISSUES  ** 

**FOR  EACH  WAREHOUSE  AREA  (TWO  THOUSAND  LBS  PER  MEASUREMENT  TON)  ** 

** YOKOHAMA  COLD  STORAGE** 

YMCSW  VARIABLE  1245 

k 

**YOKOSUKA  COLD  STORAGE  (BLDG  1390)** 

YKCSW  VARIABLE  1647 

* 

**DRY  (B-47 )  WAREHOUSE** 

DRYWW  VARIABLE  999 

k 

**A  WAREHOUSE** 

AWHEW  VARIABLE  1881 

* 

**B  WAREHOUSE** 

BWHEW  VARIABLE  2124 

★ 

**MAIN  (F-157 )  WAREHOUSE** 

MAINW  VARIABLE  381 

k 

**F  WAREHOUSE** 

FWHEW  VARIABLE  2283 

k 

**J  WAREHOUSE** 

JWHEW  VARIABLE  3096 
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** INPUT  PARAMETER  -  ENTER  ISSUE  BACKLOG  THRESHOLD  (LBS)  ***************** 
**REQUIRED  TO  SCHEDULE  AN  ADDITIONAL  TRACTOR  TRAIN  RUNS  ***************** 

**ATRN  ROUTE** 

AKTRA  VARIABLE  64000 

k 

**BTRN  ROUTE** 

BXTRA  VARIABLE  64000 

k 

**PROVISIONS  WAREHOUSE  ROUTE** 

PXTRA  VARIABLE  32000 

k 

** INPUT  PARAMETER  EXPRESSED  IN  NO.  PER  1000  ISSUES  RECEIVED  IN  PACKING*** 

k 

**NO .  ISSUES  FOR  LIGHT  OR  PARCEL  POST  PACK** 

LITEP  VARIABLE  911 


* ***** ********* ************ ******** A**************************** ****** 

**  VARIABLE  COMPUTATION  ** 

**  SYMBOLIC  NAME,  COMPUTATION  AND  DEFINITION  OF  VARIABLES  REFERENCED** 

**  DURING  THE  SIMULATION.  VARIABLE  VALUES  ARE  COMPUTED  FROM  INPUT  ** 

**  PARAMETER  VARIABLES,  OTHER  DEFINED  VARIABLES  OR  FUNCTIONS.  ** 

********;**★*****  *****  ****** A************** 

* 

**********COMPUTE  day  of  week  indicator************ 

**M0N=1  TUES=2  WED=3  THU=4  FRI=5  SAT=6  SUN=0** 

DAY  VARIABLE  N$DAYC@7 

* 

**COMPUTE  TIME  OF  DAY** 

TIME  VARIABLE  C1024OO 

* 

**NO  OF  WEEKDAY  DEMANDS  NOT  REC'D  DURING  WORKDAY  PER  1000  REQS  REC'D** 
NITDD  VARIABLE  1000-VSDAYDD 

■k 

**WEEKLY  DEMANDS  GIVEN  MONTHLY  DEMAND  LEVEL** 

^WDMND  VARIABLE  (V$DMAND*231 ) /1000 

**DAILY  DEMANDS  GIVEN  MONTHLY  DEMAND** 

DDMND  VARIABLE  ( (V$WDMND*FN$FTHNN)/1000)/3 

**DEMANDS  RECEIVED  DURING  THE  WORKDAY** 

^WRKDD  VARIABLE  (V$DDMND*V$DAYDD ) / 1000 

**DEMANDS  RECEIVED  DURING  THE  WORKDAY  AM** 

*AMDD  VARIABLE  ( ( (V$DDMND*V$NITDD)/1000)*800)/1525 

**DEMANDS  RECEIVED  DURING  THE  WORKDAY  PM** 

PMDD  VARIABLE  ( ( (V$DDMND*V$NITDD)/1000)*725)/1525 

* 

**NO  REQS  SENT  TO  REQUIREMENTS  DIV.  FOR  STOCK  CHECK  PER  1000  REQS  REC'D** 
^RQCHK  VARIABLE  V$PERPV+V$SSS 

**NO  REQS  SENT  TO  REQUIREMENTS  DIV.  FOR  STOCK** 

**CHECK  PER  1000  HARD  COPY  REQS  REC'D  ** 

^RQDIV  VARIABLE  1000*V$RQCHK/ ( 1000-V$ONLIN) 

**PROVISIONS  REQS  PER  1000  REQS  REC'D** 

PROV  VARIABLE  V$PERPV+V$SSS+V$DRY?V 

* 

**NO  OF  DEMAND  EXCEPTIONS  PER  MONTH** 

NUMEX  VARIABLE  V$DMAND*V$DMDEX/ 1000 

**NET  DEMAND  EXCEPTIONS  PER  1000  ISSUES** 

NETEX  VARIABLE  VSNUMEX*1000/ ( (V$GROSS*V$DMAND)/1000) 

* 

**TRANSACTIONS  NOT  DEMAND  EXCEPTION  PER  1000  ISSUES** 

NOTEX  VARIABLE  1000-VSNETEX 

* 

**ISSUES  NOT  WAREHOUSE  REFUSALS  PER  1000  ISSUE  DOCS  SENT  TO  WAREHOUSE** 
^NOTWR  VARIABLE  1000-V$WHREF 

**SERVICE  TIME  VARIABLES  (SUM  OF  3  FUNCTION  CALLS)******************** 

* 

INEXP  FVARIABLE  FN$FFORT+FN$FFORT+FN$FFORT+ . 5 


**SERVICE  TIME  VARIABLES  FOR  GROUPS  OF  THREE  -  SERVICE  TIME  MEAN  **** 
**MULTIPLIED  BY  V$INEKP  FOR  SERVICE  TIME  CONSTRUCTED  FROM  MEANS  -  **"* 
**SUM  OF  THREE  SERVICE  TIME  FUNCTION  CALLS  FOR  SERVICE  TIMES  **** 

^^CONSTRUCTED  FROM  CONTINUOUS  DISTRIBUTIONS  **** 

SKCKS  VARIABLE  FN$FELEV*V$INEXP 

k 

RTES  VARIABLE  FN$FTWEL*V$INEXP 

* 

DEEXS  VARIABLE  FN  $  FTHTN  *V  $ I NEXP 

* 

SCSOS  VARIABLE  FN$FSXTN*V$INEXP 

k 

YM CSS  VARIABLE  FN$FEITN*V$INEXP 

k 

YKCSS  VARIABLE  FN $ FNNTN*V $ I NE XP 

k 

DRYWS  VARIABLE  FN$FTWEN*V$INEXP 

* 

^AWHES  VARIABLE  FN$FTWON+FN$FTWON+FN$FTWON 

BWHES  VARIABLE  FN  $  FTWTW+FN  $  FTWTW+FN  $  FTWTW 

k 

^MAINS  VARIABLE  FN$FTWTH*V$INEXP 

^FWHES  VARIABLE  FN$FTWFR+FN$FTWFR+FN$FTWFR 

JWHES  VARIABLE  FN$FTWFV+FN$FTWFV+FN$FTWFV 

k 

^HVYPS  VARIABLE  FN$FTWSX*V$INEXP 

^LITPS  VARIABLE  FN$FTWSV*V$INEXP 

**ESTIMATED  WEIGHT  OF  TRANSACTIONS  AWAITING  THE  TRACTOR  TRAINS******** 
k 

**ATRN  ROUTE** 

^AWGHT  VARIABLE  (CH$MAINC*V$MAINW)+(CH$FCH*V$FWHEW) 

**BTRM  ROUTE** 

BWGHT  VARIABLE  (CH$ACH*V$AWHEW)+(CH$BCH*V$BWHEW)+(CH$JCH*V$ JWHEW) 

k 

**PROVISIONS  WAREHOUSE  ROUTE** 

^PWGHT  VARIABLE  CH$PTRNC*( (V$YKCSW+V$DRYWW)/2) 

**VARIABLE  COUNTS  GROUPS  OF  3  LEAVING  DUTY  SECTION  MODULE************* 
COUNT  VARIABLE  N$DUTTR@3 


********************************************************************** 

**  BOOLEAN  VARIABLE  COMPUTATION  ** 

**  SYMBOLIC  NAME,  COMPUTATION  AND  DEFINITION  OF  BOOLEAN  VARIABLES  ** 

**  REFERENCED  IN  THE  SIMULATION.  BOOLEAN  VARIABLES  ARE  USED  IN  THE  ** 

**  SIMULATION  TO  CONTROL  OPERATIONS  SCHEDULING.  ** 

********************************  *  ***************************  ********** 

* 

**WORKDAY  INDICATOR,  TRUE  (1)  IF  MONDAY  THROUGH  FRIDAY** 

WKDAY  BVARIABLE  V$DAY 1 GE 1 K1*V$DAY 1 LE 1 K5 

* 

**LUNCHTIME  INDICATOR,  TRUE  IF  1201  -  1245  ON  WORKDAY 
LUNCH  BVARIABLE  V$TIME 1 GE 1 K1201*V$TIME 1 LE ' K1275*BV$WKDAY 1 E ' K1 

* 

**NIGHTTIME  INDICATOR,  TRUE  IF  BEFORE  0801  OR  AFTER  1645  ON  WORKDAY 
NIGHT  BVARIABLE  { V$TIME 1 GE 1 K1676+V$TIME 1 LE 1 K800 ) *BV$ WKDAY 1 E 1 K1 

* 

**WORKING  HOURS  INDICATOR,  TRUE  IF  0801  -  1200  OR  1246  -  1645  ON  WORKDAY 
WORKH  BVARIABLE  BV$LUNCH ' E 1 KO*BV$NIGHT 1 E ' KO*BV$WKDAY 1 E 1 K1 

* 

**DEPOT  OPEN  INDICATOR,  TRUE  IF  0801  -  1645  ON  WORKDAY 
BVSLUNCH 1 E ' Kl+BVSWORKH 1 E 1 K1 


OPEN 

BVARIABLE 

PTIME 

BVARIABLE 

PRTWO 

BVARIABLE 

PRTHR 

BVARIABLE 

BTIME 

BVARIABLE 

DTIME 

BVARIABLE 

V$TIME 1 E ' 800+VSTIME 1 E 1 1000+VSTIME 1 E ' 1275+VSTIME ' E 1 1475 

SET  TO  TRUE  AT  IPG2  PRINT  TIMES 

BV$ WKDAY 1 E 1 K1*BV$PTIME 1 E 1 K1 

SET  TO  TRUE  ON  WORKDAYS  TO  PRINT 
IPG2  BATCH 

BV$ WKDAY ' E 1 1*V$TIME 1 E ' 800 

SET  TO  TRUE  ON  WORKDAYS  TO  PRINT 
IPG3  BATCH 

V$TIME ' E ' 900+VSTIME ' E ' 1100+VSTIME ' E 1 1375+VSTIME 1 E ' 1525 

SET  TO  TRUE  AT  ISSUE  DOC  DELIVERY 
TIMES 

BV$ WKDAY 1 E 1 K1*BV$BTIME 1 E 1 K1 

SET  TO  TRUE  AT  DELIVERY  TIME  ON 
WORKDAYS 


* 

* 

* 

* 

* 

* 

**BOOLEAN  VARIABLE  SET  TO  TRUE  IF  ISSUE  FOR  BEARER  PICK-UP** 

BEAR  BVARIABLE  PI 1 E ' K7+P1 ' E ' K5+P1 1 E ‘ K3 

* 

**EOOLEAN  VARIABLE  SET  TO  TRUE  ON  EVERY  THIRD  TRANSACTION  LEAVING  DUTY** 
THREE  BVARIAELE  VSCOUNT'E'O 


**************  ******  ************************************************** 
**  TRANSACTION  PRIORITIES  AND  PARAMETERS  ** 

**  KEY  TO  PRIORITIES  AND  PARAMETERS  ASSIGNED  AND  REFERENCED  DURING  ** 
**  THE  SIMULATION.  ** 

*************************************************************  ******** 
* 


^PRIORITY 

* 

REQ  PRIORITY 

MATCHES  PI 

*pi 

REQ  PRIORITY 

IPG1  BWT  =  7 

* 

IPG1  (ALL  OTHER)  =  6 

* 

IPG2  BWT  =  5 

* 

IPG2  CASREPT 

* 

(MOT  BWT)  =  4 

* 

IPG2  QUICK  PICK  =  3 

* 

IPG2  (ALL  OTHER)  =  2 

* 

IPG3  =  1 

*P2 

STORAGE  AREAS 

YOKOHAMA  COLD  STORAGE 

=  1 

* 

YOKOSUKA  COLD  STORAGE 

=  2 

* 

(BUILDING  1390) 

* 

DRY  PROVISIONS 

=  3 

* 

(B-47) 

* 

A  AREA  WAREHOUSES 

=  4 

* 

(A-19) 

* 

B  AREA  WAREHOUSES 

=  5 

* 

(B-33 ,B-45 ,B-46) 

* 

MAIN  WAREHOUSE 

=  6 

* 

(F-157) 

* 

F  AREA  WAREHOUSES 

=  7 

* 

(F-8,F-9,F-10,F-11, 

* 

F-12 , F-13 , F-14) 

* 

J  AREA  WAREHOUSES 

=  8 

* 

( J-ll , J-12  AND  GAS, 

* 

* 

LUMBER  AND  DRUM  YARDS) 

* 

*P3 

TRANSACTION  POINT  OF 

PARAMETER  VALUES  EVALUATED 

* 

PROGRESS  PARAMETER 

BY  FUNCTIONS  FTHIR  AND 

FTHON 

* 

(SPECIFIES  DUTY  SECTION 

* 

PROCESSING  REQUIRED  AND/ 

* 

OR  POINT  OF  RETURN  FOR 

* 

TRANSACTIONS  NOT 

* 

PROCESSED  BY  THE  DUTY 

* 

SECTION) 

*P4 

NSD  TRANSPORTATION 

MAJOR  CUSTOMER  (PWC.SRF)  =  1 

* 

DESTINATIONS 

NOTE:  NOT  ASSIGNED  IN 

* 

PROVISIONS  STORAGE  LOCATIONS 

* 

PACKING  DIVISION 

=  2 

* 

FREIGHT  TERMINAL  DIVISION  =  3 

*P5 

ISSUE  WEIGHT 

WEIGHT  ASSIGNED  TO  TRANSACTIONS 

* 

EXPRESSED  IN  LBS 

*P6 

STOCK  STATUS 

NIS/NC  =  1 

* 

IN  STOCK  =  2 

*P7 

DEMAND  EXCEPTION  STATUS 

PROCESSED  DEMAND  EXCEPTION  =  1 

*P8 

WAREHOUSE  REFUSAL  STATUS 

WAREHOUSE  REFUSAL  =  1 

********************************************************************** 
**  STORAGE  DEFINITIONS  ** 

**  SYMBOLIC  ADDRESS,  CAPACITY  AND  BRIEF  EXPLANATION  OF  NSD  ** 

**  FUNCTIONAL  AREAS  MODELED  AS  STORAGES  WITHIN  THE  SIMULATION.  ** 

**  CAPACITIES  REFLECT  NUMBER  OF  PERSONNEL  WORKING  IN  THE  MODELED  ** 

**  WORKCENTER  EXCEPT  FOR  THE  ATRN  AND  BTRN  STORAGES  WHICH  REFLECT  ** 

**  TRACTOR  TRAIN  CAPACITY  IN  POUNDS.  ** 

********************************************************************** 


STORAGE 


STORAGE 


STORAGE 


STORAGE 


STORAGE 


STORAGE 


STORAGE 


STORAGE 


S$SKCK,6 


SSCRTE , 5 


S$DRTE , 2 


SSDEEX, 2 


STORAGE  SSSCPR, 100000 


STORAGE  S$CSPR, 100000 


S$SCNT , 4 


STORAGE  SSSTOF , 1 


STORAGE  S$DLVR, 100000 


STORAGE  SSYMCS , 11 


STORAGE  S$YKCS , 4 


STORAGE  S$DRYW, 2 


S$AWHE , 2 


S$BWHE , 2 


STORAGE  S$MAIN, 8 


S$FWHE , 1 


STORAGE  S$ JWHE , 4 


NO  OF  CLERKS  IN  REQUIREMENTS 
PERFORMING  STOCK  CHECKS 

NO  OF  RTE  OPERATORS  IN  CUST  SERV 
ENTERING  REQS 

NO  OF  RTE  OPERATORS  IN  DPSC 
ENTERING  REQS 

NO  OF  CLERKS  IN  CUST  SERV 
PROCESSING  DEMAND  EXCEPTIONS 

STORAGE  CONTROL  PRINTER,  UNLIMITED 
CAPACITY 

CUST  SERV  PRINTER,  UNLIMITED 
CAPACITY 

NO  OF  STORAGE  CONTROL  PERSONNEL 
MARKING, BURSTING  AND  SORTING 
ISSUE  DOCUMENTS 

NO  OF  STORAGE  OFFICE  PERSONNEL 
MARKING, BURSTING  AND  SEGREGATING 
ISSUE  DOCUMENTS 

ISSUE  DOC  DELIVERY  TO  YOKOHAMA 
COLD  STORAGE,  UNLIMITED  CAPACITY 

NO.  OF  WAREHOUSE  PERSONNEL  AT 
YOKOHAMA  COLD  STORAGE  IN  ISSUE  AND 
SHIPMENT  PREP  OPERATIONS 

NO.  OF  WAREHOUSE  PERSONNEL  AT 
BUILDING  1390  (YOKSUKA  COLD  STOR.) 
IN  ISSUE  AND  SHIPMENT  PREP 
OPERATIONS 

NO.  OF  WAREHOUSE  PERSONNEL  AT 
YOKOSUKA  DRY  STORAGE  (B-47)  IN 
ISSUE  AND  SHIPMENT  PREP  OPERATIONS 

NO.  OF  WAREHOUSE  PERSONNEL  AT 
A  AREA  WAREHOUSES  IN  ISSUE  OPS 

NO.  OF  WAREHOUSE  PERSONNEL  AT 
B  AREA  WAREHOUSES  IN  ISSUE  OPS 

NO.  OF  WAREHOUSE  PERSONNEL  AT 
F-157  IN  ISSUE  OPS 

NO.  OF  WAREHOUSE  PERSONNEL  AT 
F  AREA  WAREHOUSES  IN  ISSUE  OPS 

NO.  OF  WAREHOUSE  PERSONNEL  AT 
J  AREA  WAREHOUSES  IN  ISSUE  OPS 
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STORAGE 

S$ATRN, 32000 

CAPACITY,  EXPRESSED  IN  POUNDS,  OF 
THE  ON-BASE  TRACTOR 

TRAIN  (A-ROUTE) 

STORAGE 

S$BTRN, 32000 

CAPACITY,  EXPRESSED  IN  POUNDS  OF 
THE  ON-BASE  TRACTOR 

TRAIN  (B-ROUTE) 

STORAGE 

S$PTRN , 32000 

PROVISIONS  TRACTOR  TRAIN, 

CAPACITY  NOT  REFERENCED  DURING 
SIMULATION 

STORAGE 

SSLITP ,  5 

NO  OF  PACKERS  IN  LIGHT  PACK  LINE 

STORAGE 

S$HVYP , 3 

NO  OF  HEAVY  PACK  CREWS 

STORAGE 

S$DUTY , 2 

TWO  MAN  DUTY  SECTION 

STORAGE 

S$BIKE, 100000 

BICYCLE  MESSENGER  DELIVERING  ISSUE 
DOCUMENTS  TO  YOKOSUKA  STORAGE 
LOCATIONS 
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**  FUNCTIONS  ** 

**  DEFINITION  OF  FUNCTIONS  USED  IN  THE  SIMULATION  PROGRAM.  FUNCTIONS** 

**  ARE  PARTIONED  BY  TYPE.  ** 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk  k  ****** 
k 

kk PARAMETER  ASSIGNMENT  FUNCTIONS************************************** 

* 

FONE  FUNCTION  RN1(D7  REQ  PRIORITY 

0.66696,1/. 96695 ,2/. 96978, 3/. 96995, 4/. 98713, 5/. 99983 ,6/1. 0,7 

FTWO  FUNCTION  RN1,D8  WAREHOUSE  LOCATION  ASSIGNMENT 

0.17127,1/. 22920, 2/. 30846, 3/. 35334 ,4 
0.40113, 5/. 90023, 6/. 94454, 7/ 1.0, 8 

k 

*  ASSIGNS  FUNCTION  TO  PROVIDE  ISSUE 

FTHRE  FUNCTION  P2,E8  DESTINATION  IN  DUTY  SECTION  MODULE 

1 , FNSFFOUR/2 , FN$FFOUR/3 , FNSFFIVE/4 , FN$FS IX/ 5 , FNSFSEVE 
6 , FNSFEIGH/7 , FNSFNINE/8 , FN$FTEN 

FFOUR  FUNCTION  RN1,D2  BLDG  1390  ISSUE  DEST.  ASSIGN. 

0.9326,1/1.0,2 

FFIVE  FUNCTION  RN1,D2  B-47  ISSUE  DESTINATION  ASSIGNMENT 

0.6264,1/1.0,2 

FSIX  FUNCTION  RN1,D3  A  AREA  ISSUE  DESTINATION  ASSIGN. 

0.0389,1/. 6897, 2/1. 0,3 

FSEVE  FUNCTION  RN1,D3  B  AREA  ISSUE  DESTINATION  ASSIGN. 

0.2888,1/. 7744, 2/1. 0,3 

k 

FEIGH  FUNCTION  RN1,D3  F-157  ISSUE  DESTINATION  ASSIGN. 

0.0167,1/. 6772, 2/1. 0,3 

FNIME  FUNCTION  RN1,D3  F  AREA  ISSUE  DESTINATION  ASSIGN. 

0.3662,1/. 8054, 2/1. 0,3 

k 

FTEN  FUNCTION  RN1,D3  J  AREA  ISSUE  DESTINATION  ASSIGN. 

0.1357, 2/. 7312, 2/1. 0,3 

**SERVICE  TIME  ASSIGNMENT  FUNCTIONS*********************************** 

k 

FELEV  FUNCTION  RN1,D2  STOCK  CHECK  SERVICE  TIME 

0.0, 0/1. 0,1 

X 

FTWEL  FUNCTION  RN1,D2  REMOTE  TERMINAL  ENTRY  SERVICE  TIME 

0.0, 0/1. 0,1 

*  FUNCTION  ASSIGNMENT  FOR  DEMAND 

FTHTN  FUNCTION  P8,E2  EXCEPTION  PROCESSING 

0 , FNSFFRTN/ 1 , FN$FFFTN 

FFRTN  FUNCTION  RN1,D2  DEMAND  EXCEP .  PROCESSING  TIME 

0.0, 0/1. 0,1 

FFFTN  FUNCTION  RN1,D2  WAREHOUSE  REF.  PROCESSING  TIME 

0.0, 0/1. 0,5 

* 

FSXTN  FUNCTION  RN1,D2 

0.0, 0/1. 0,1 


STORAGE  CONTROL/ STORAGE  OFFICE 
ISSUE  DOC  HANDLING  TIME 


*  *o 


*  ASSIGNS  FUNCTION  TO  PROVIDE 

FSVTN  FUNCTION  P2,E8  WAREHOUSE  SERVICE  TIME 

1 , FNSFEITN/2 , FNSFNNTN/3 , FN$FTWEN/4 , FNSFTWON 
5 , FNSFTWTW/6 , FNSFTWTH/7 , FN$FTWFR/8 , FN$FTWFV 

FEITN  FUNCTION  RN1,D2  YOKOHAMA  C/S  PICK  TIME 

0.0,0/1.0,17 

•k 

FNNTN  FUNCTION  RN1,D2  YOKOSUKA  C/S  (BLDG  1390)  PICK  TIME 

0.0,0/1.0,17 

k 

FTWEN  FUNCTION  RN1,D2  B-47  PICK  TIME 

0.0, 0/1. 0,7 
k 

FTWON  FUNCTION  RN1 , C24  A-19  PICK  TIME 

0.038, 3/. 11 5, 5/. 192, 7/. 269, 8/. 308, 10/. 333, 12 
0.359, 13/. 423, 15/. 474, 17/ .551 ,18/ .628,20 
0.654, 22/. 692, 23/. 744, 25/ .756,27/ .769, 28/. 859, 30 
0.372, 32/. 936, 33/ .949,40/ .962,43/ .974, 47/. 987, 50/1. 0,57 

FTWTW  FUNCTION  RN1,C6  B  WAREHOUSE  PICK  TIME 

0.045, 7/. 545, 8/. 682, 10/. 818, 13/. 955, 17/ 1.0, 25 

k 

FTWTH  FUNCTION  RN1,D2  F-157  PICK  TIME 

0.0, 0/1. 0,8 

k 

FTWFR  FUNCTION  RN1,C9  F  WAREHOUSE  PICK  TIME 

0.1 53,1/. 292, 2/. 319, 3/  .472,5 
0.514, 7/. 681, 8/. 917, 10/ .958,12/1.0,17 

k 

FTWFV  FUNCTION  RN1.C23  J  WAREHOUSE  PICK  TIME 

0.008, 3/. 035, 5/. 185, 7/. 385, 8/. 462, 10/. 547, 12 
0.585, 13/. 600, 15/. 677, 17/. 692, 18/. 708, 20/. 754, 25 
0.770, 27/. 854, 33/. 835, 37/. 892, 40/ .915,42/ .931,45 
0.946, 47/. 969, 50/. 935, 53/. 992, 200/1 .0,267 

FTWSX  FUNCTION  RN1.D2  HEAVY  PACK  SERVICE  TIME 

.0,0/1.0,42 

FUNCTION  ASSIGNMENT  FOR  LIGHT/ 

FTWSV  FUNCTION  RN1,E2  PARCEL  POST  PROCESSING  TIME 

0.939 , FNSFTWEI/1 .0 , FN$ FTWNN 

FTWEI  FUNCTION  RN1,D2  LIGHT  PACK  SERVICE  TIME 

0.0, 0/1. 0,7 

k 

FTWNN  FUNCTION  RN1,D2  PARCEL  POST  PACK  SERVICE  TIME 

0.0, 0/1. 0,3 

* 

’'^TRANSACTION  TRANSFER  LOCATION  ASSIGNMENT**************************** 

k 

*  TRANSFER  LOCATION  FOR  TRANSACTIONS 

*  NOT  HANDLED  BY  THE  DUTY  SECTION 

FTHIR  FUNCTION  P3.D26  OR  NOT  RESULTING  IN  AN  ISSUE 

0 , SKCKQ/ 1 , CRTEQ/2 , DTNIS/3 , DEEXO/4 , SCNTP/5 , STOFp/6 , DLVRQ/7 , BIKEp 
8 , YHCSO/9 , YKCSP/10 , DRYWQ/11 , AWHEQ/12 , EWHEQ/ 13 ,  IiAINQ/ 14 , FWHEP/lS , JWHEQ 
16  ,  PQUE/17  ,  AQUE/13  ,  BQUE/19  ,  MQUE/20  ,  FPUE/21 ,  JQUE/22  ,HVYPQ/23  ,'LITPQ 
24 , ALLCT / 2  5 , DTWR 


t-H*  -K  r-ir-*  *  vD'K  K  *  *  <M*  * 


■*  TRANSFER  LOCATION  WITHIN  DUTY 

FTHON  FUNCTION  P3,D23  SECTION  BASED  ON  P3 

0 , PZERO/ 1 , PONE/3 ,PTHRE/4, PFOUR/ 5 ,PFOUR/6 , PSIX/7 , PSIX/8 , PEIGH 
9 , PEIGH/10 , PEIGH/I1 , PEIGH/12 , PEIGH/ 13 , PEIGH/ 14 , PEIGH/15 , PEIGH/16 ,PSXTN 
17 , PSXTN/ 18 , PSXTN/ 1 9 , PSXTN/ 20 , PSXTN/ 21 , PSXTN/ 22 , PTWTW/ 23 , PTWTH 

FTHTW  FUNCTION  P2,D8  WAREHOUSE  LOCATION  TRANSFER 

, YMCSQ/2 , YKCSQ/3 , DRYWQ/4 , AWHEQ/5 , BWHEQ/6 , MAINQ/7 , FWHEQ/8 , JWHEQ 

CONTROL  TRANSACTION  DESTINATION 

FTHTH  FUNCTION  P1,D8  IN  SIMULATION  TIME  CONTROL  MODULE 

, SONE/2 , STWO/3 , STHRE/4 , SFOUR/5 , SFIVE/6 , SSIX 
, SSEVE/ 8 , SEIGH 

TRANSFER  LOCATION  FOR  TRACTOR 

FTHFR  FUNCTION  P2(D2  TRAIN  OVERFLOW  (A  ROUTE) 

,MLINK/7 , FLINK 

TRANSFER  LOCATION  FOR  TRACTOR 

FTHFV  FUNCTION  P2,D3  TRAIN  OVERFLOW  (B  ROUTE) 

, ALINK/ 5 , BLINK/8 , JLINK 

^TRANSPORTATION  TIME  ASSIGNMENT  FUNCTIONS**************************** 

BICYCLE  MESSENGER  ROUTE  TIME 

FTHSX  FUNCTION  P2,D7  ASSIGN.  FOR  ISSUE  DOC  DELIVERY 

,73/3,18/4,50/5,28/6,7/7,7/8,75 

CUSTOMER  SERVICE  TO  WAREHOUSE 

FTHSV  FUNCTION  P2,D8  TRANSPORTATION  TIMES 

1,150/2,10/3,3/4,15/5,5/6,2/7,3/8,13 

*  WAREHOUSE  LOCATION  TO  BLDG  J-39 

FTHEI  FUNCTION  P2,D7  TRANSPORTATION  TIMES 

2,12/3,7/4,13/5,3/6,5/7,8/8,7 

X 

**DAILY  DEMAND  LEVEL  ASSIGNMENT  FUNCTIONS**************************** 

* 

*  AVERAGE  %  OF  WEEKLY  DEMANDS 

FTHNN  FUNCTION  V$DAY,D7  EXPERIENCED  ON  EACH  DAY 

0,21/1,163/2,150/3,200/4,201/5,205/6,55 

■k 

**STANDARD  DISTRIBUTION  FUNCTIONS************************************* 

* 

FFORT  FUNCTION  RN1,C24  INVERSE  EXPONENTIAL  FUNCTION 

0.0,0/.l, .104/. 2, .222/. 3, .355/. 4, .509/. 5, .69 
0.6, .915/. 7, 1.2/. 7 5, 1.38/. 8, 1.6/. 84, 1.83/. 88, 2. 12 
0.9, 2. 3/. 92, 2. 52/. 94, 2. 81/ .95,2.99/ .96, 3. 2/. 97, 3. 5 
0.98, 3. 9/. 99, 4. 6/. 995, 5. 3/ .998, 6. 2/. 999, 7/ .9998,8 
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**  MASTER  SCHEDULE  CONTROL  ** 

**  SIMULATE  ONE  WEEK  OF  OPERATIONS  IN  INCREMENTS  OF  .01  HOURS.  A  ** 

**  CONTROL  TRANSACTION  IS  GENERATED  AT  THE  BEGINNING  OF  EACH  DAY.  ** 

**  ADVANCE  BLOCKS  ARE  USED  TO  MOVE  THE  TRANSACTION  THROUGH  A  ** 

**  WORKDAY  SCHEDULE.  AT  APPROPRIATE  TIMES,  STORAGES  REPRESENTING  ** 

**  DEPOT  WORKCENTERS  ARE  OPENED  AND  CLOSED  AND  TRANSACTIONS  ARE  ** 

**  LINKED  TO  AND  UNLINKED  FROM  USER  CHAINS  BY  SENDING  THE  CONTROL  ** 

**  TRANSACTION  TO  THE  STORAGE  CONTROL  AND  USER  CHAIN  CONTROL  ** 

**  MODULES.  ** 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

k 


GENERATE  16800  GENERATE  SIMULATION  CONTROL 

*  TRANSACTION 

TERMINATE  1  TERMINATE  SIMULATION 

; k 

**GENERATE  A  CONTROL  TRANSACTION  AT  THE  BEGINNING  OF  EACH  DAY********* 

k 


DAYC 

* 

GENERATE 

2400,0,1 

GENERATE  CONTROL 

TRANSACTION 

TEST  E 

BV$WKDAY,K1, SEIGH 

SEND  TO 

SEIGH  IF 

SAT/SUN  ELSE  NEXT 

k 

BLOCK 

ASSIGN 

1  ,K1 

TAG  FOR 

RETURN 

k 

TRANSFER 

, UNAVL 

SEND  TO 

UNAVL 

SONE 

ADVANCE 

800 

ADVANCE 

TO  0801 

ASSIGN 

1  ,K2 

TAG  FOR 

RETURN 

TRANSFER 

,  AVAIL 

SEND  TO 

AVAIL 

STWO 

ASSIGN 

1  ,K3 

TAG  FOR 

RETURN 

k 

TRANSFER 

, START 

SEND  TO 

START 

STHRE 

ADVANCE 

400 

ADVANCE 

TO  1201 

ASSIGN 

1  ,K4 

TAG  FOR 

RETURN 

k 

TRANSFER 

, UNAVL 

SEND  TO 

UNAVL 

SFOUR 

ADVANCE 

75 

ADVANCE 

TO  1246 

ASSIGN 

1  ,K5 

TAG  FOR 

RETURN 

TRANSFER 

, AVAIL 

SEND  TO 

AVAIL 

SFIVE 

ASSIGN 

1  ,K6 

TAG  FOR 

RETURN 

* 

TRANSFER 

, START 

SEND  TO 

START 

SSIK 

ADVANCE 

400 

ADVANCE 

TO  1646 

ASSIGN 

1  ,K7 

TAG  FOR 

RETURN 

TRANSFER 

, UNAVL 

SEND  TO 

UNAVL 

SSEVE 

ASSIGN 

1 ,  K3 

TAG  FOR 

RETURN 

TRANSFER 

, FNISH 

SEND  TO 

FNISH 

SEIGH 

TERMINATE 

TERMINATE  CONTROL 

TRANSACTION 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 


kk 


STORAGE  CONTROL 

**  AVAILABILITY  OF  STORAGES  IS  CONTROLLED  BY  THE  MASTER  SCHEDULE 
**  CONTROL  MODULE.  SUNAVAIL  CLOSES  STORAGES,  SAVAIL  OPENS  THEM 
**  TO  COINCIDE  WITH  NSD  NORMAL  WORKDAY  SCHEDULE.  PROCESSING  OF 
**  TRANSACTIONS  IN  STORAGES  WHEN  THEY  ARE  MADE  UNAVAILABLE  IS 
**  COMPLETED. 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk kkkk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 
k 


kk 

kk 

kk 

kk 

kk 

kk 


UNAVL 

SUNAVAIL 

SKCK 

SUNAVAIL 

CRTE 

SUNAVAIL 

DRTE 

SUNAVAIL 

DEEX 

SUNAVAIL 

SCNT 

SUNAVAIL 

STOF 

SUNAVAIL 

YMCS 

SUNAVAIL 

YKCS 

SUNAVAIL 

DRYW 

SUNAVAIL 

AWHE 

SUNAVAIL 

BWHE 

SUNAVAIL 

MAIN 

SUNAVAIL 

FWHE 

SUNAVAIL 

JWHE 

SUNAVAIL 

LITP 

SUNAVAIL 

HVYP 

TRANSFER 

FN , FTHTH 

AVAIL 

SAVAIL 

SKCK 

SAVAIL 

CRTE 

SAVAIL 

DRTE 

SAVAIL 

DEEX 

SAVAIL 

SCNT 

SAVAIL 

STOF 

SAVAIL 

YMCS 

SAVAIL 

YKCS 

SAVAIL 

DRYW 

SAVAIL 

AWHE 

SAVAIL 

BWHE 

SAVAIL 

MAIN 

SAVAIL 

FWHE 

SAVAIL 

JWHE 

SAVAIL 

LITP 

SAVAIL 

HVYP 

TRANSFER 

FN , FTHTH 

RETURN  TO  SIMULATION  TIME  CONTROL 


RETURN  TO  SIMULATION  TIME  CONTROL 


********************************************************************** 
**  USER  CHAIN  CONTROL  ** 

**  TRANSACTIONS  ARE  PLACED  ON  USER  CHAINS  TO  SAVE  EXECUTION  TIME  ** 

**  AND  TO  MAINTAIN  CONTROL  OF  TRANSACTIONS  THAT  MUST  BE  WORKED  BY  ** 

**  THE  DUTY  SECTION.  THE  "FNISH"  SEGMENT  REMOVES  ALL  TRANSACTIONS  ** 

**  FROM  LISTED  USER  CHAINS  AT  THE  END  OF  THE  WORKDAY  AND,  WITHIN  ** 

**  THEIR  RESPECTIVE  MODULES,  HIGH  PRIORITY  REQUISITIONS  ARE  SENT  TO  ** 

**  THE  DUTY  SECTION  MODULE  FOR  PROCESSING.  THE  "START"  SEGMENT  ** 

**  RELEASES  ENOUGH  TRANSACTIONS  TO  FILL  THE  RESPECTIVE  STORAGES  ** 

**  EACH  WORKDAY  MORNING  AND  IMMEDIATELY  AFTER  LUNCH.  ** 

********************************************************************** 
* 


FNISH  UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
TRANSFER 

it 

START  UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
UNLINK 
TRANSFER 


SKCKC , SKCKT , ALL , BACK 
CRTEC , CRTET , ALL , BACK 
DEEXC,DEEXT, ALL, BACK 
SCNTC , SCNTT , ALL , BACK 
STOFC , STOFT , ALL , BACK 
YMCSC , YMCST , ALL , BACK 
YKCSC,YKCST, ALL, BACK 
DRYWC , DRYWT , ALL , BACK 
AWHEC , AWHET , ALL , BACK 
BWHEC , BWHET , ALL , BACK 
MAINC , MAINT , ALL , BACK 
FWHEC , FWHET , ALL , BACK 
JWHEC , JWHET , ALL , BACK 
HVYPC , HVYPT , ALL , BACK 
LITPC , LITPT , ALL , BACK 
FN , FTHTH 

SKCKC, SKCKE, 6, BACK 
CRTEC, CRTEE, 5, BACK 
DRTEC , DRTEE , 2 , BACK 
DEEXC , DEEXE , 2 , BACK 
SCNTC, SCNTE, 4, BACK 
STOFC, STOFE,l, BACK 
YMCSC, YHCSE, 11, BACK 
YKCSC , YKCSE , 4 , BACK 
DRYWC , DRYWE , 2 , BACK 
AWHEC, AWHEE, 2, BACK 
BWHEC, BWHEE, 2, BACK 
MAINC, MAINE, 8, BACK 
FWHEC , FWHEE , 1 , BACK 
JWHEC, JWHEE, 4, BACK 
HVYPC, HVYPE, 3, BACK 
LITPC, LITPE, 5, BACK 
FN , FTHTH 


RETURN  TO  SIMULATION  TIME  CONTROL 


RETURN  TO  SIMULATION  TIME  CONTROL 


★  A*****************:****************************:*********************** 

**  REQUISITION  GENERATION  ** 

**  IN  THIS  MODULE,  SPLIT  BLOCKS  REFERENCE  VARIABLES  DEFINED  IN  ** 

**  TERMS  OF  INPUT  PARAMETERS  SET  BY  THE  USER  TO  GENERATE  ** 

**  TRANSACTIONS  AT  THE  DEMAND  LEVEL  SPECIFIED  BY  THE  USER.  ** 

**  TRANSACTIONS  ARE  ADVANCED  INTO  THE  MODEL  AT  A  UNIFORM  RATE,  ** 

**  THOUGH  THE  RATES  ARE  ADJUSTED  TO  MATCH  REAL  SYSTEM  ARRIVAL  ** 

**  CHARACTERISTICS.  FOLLOWING  GENERATION,  REQUISITIONS  ARE  ASSIGNED  ** 
**  A  PRIORITY  MATCHING  THE  PARAMETER  1  ASSIGNMENT.  SAVEVALUES  THEN  ** 
**  RECORD  THE  TOTAL  NUMBER  OF  REQS  GENERATED  AND  THE  NUMBER  ** 

**  IN  EACH  PRIORITY  GROUP.  ** 

**  NOTE :  ** 

**  ENTITIES  FLOWING  THROUGH  GPSS  PROGRAMS  ARE  KNOWN  AS  TRANSACTIONS . ** 
**  THE  TERM  "TRANSACTION"  WILL  BE  USED  IN  THIS  PROGRAM  AS  A  GENERIC  ** 
**  TERM  FOR  REQUISITIONS  IN  ANY  STAGE  OF  PROCESSING.  IN  MODULE  ** 

**  DESCRIPTIONS  AND  COMMENTS,  TRANSACTIONS  MAY  BE  CALLED  REQS  ** 

**  (REQUISITIONS) ,  ISSUE  DOCS  (ISSUE  DOCUMENTS)  OR  ISSUES  (AFTER  ** 
**  WAREHOUSE  PICK)  AS  APPROPRIATE  TO  THE  MODULE  TO  CLARIFY  THE  ** 

**  PROCESS  BEING  MODELED.  TRANSACTIONS  USED  IN  SCHEDULE  CONTROL  ** 
**  SECTIONS  WILL  ALWAYS  BE  REFERRED  TO  AS  CONTROL  TRANSACTIONS.  ** 

■k  -k  -k  -k  9c  *  -k  -k  x  *  *  *  -k  -k  x  *  -k  -k  -k  -k  *  x  *  *  *  *  *  *  *  *  *  *  1c  *  -k  *  k  k  *:  k  k  k  k  k  k  k  *  k  k  k  k  *  k  -k  k  k  k  k  k  *  -k  k  *  k  *  k  k  k  k 

**  NOTE :  ** 

**  GPSS  QUEUE  AND  DEPART  BLOCKS  ARE  PAIRED  BEFORE  MOST  STORAGES  TO  ** 
**  GATHER  QUEUE  STATISTICS  PROVIDED  IN  THE  OUTPUT.  SO  THAT  QUEUE  ** 

**  STATISTICS  REFLECT  ACTUAL  DEMAND  LEVELS  SIMULATED,  ALL  ** 

**  TRANSACTIONS  JOINING  AND  DEPARTING  QUEUES  ARE  COUNTED  AS  THREE.  ** 
**  TRANSACTIONS  ARE  SPLIT  AND  INDIVIDUALLY  QUEUED  IN  THE  DUTY  ** 

**  SECTION  MODULE.  STORAGES  ARE  BRACKETED  BY  ENTER  AND  LEAVE  ** 

**  STATEMENTS  TO  LIMIT  TRANSACTION  ACCESS  TO  THE  DEFINED  CAPACITY  ** 
**  OF  THE  STORAGE.  BECAUSE  THE  PURPOSES  OF  THESE  BLOCKS  ARE  STANDARD** 
**  THROUGHOUT  THE  PROGRAM.  THEY  WILL  NOT  GENERALLY  BE  COMMENTED.  ** 

k  -k  k  k  k  k  rz  k  k  k  k  k  k  k  k  k  k  k  ★  'k  k  k  k  k  k  n  k  *  -k  k  k  k  k  k  k  k  k  k  *  k  k  k  k  k  k  -k  k  k  k  k  k  k  k  *  *  k  k  k  k  *  k  k  *  k  *  *  k  k  k  k 
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**AM  REQUISITION  GENERATION  (WEEKDAY)********************************* 


GENERATE  2400 ,,!,,, 8PH 


TEST  E 

k 

SPLIT 

k 

AMAD  ADVANCE 


BV$WKDAY , K1 , RQTRM 
V$AMDD , AMAD 
400,400 


TRANSFER  ,PRIAS 


GENERATE  A  SINGLE  TRANSACTION  AT 
0001  EACH  DAY 

TRANSFER  TO  NEXT  BLOCK  IF  ON  A 
WORKDAY,  ELSE  TO  RQTRM 
SPLIT  TRANSACTION  INTO  THE  NUMBER 
OF  REQS  REC'D  DURING  WORKDAY  AM 
SPREAD  REQUISITION  FLOW  UNIFORMLY 
THROUGHOUT  WORKDAY  AM 
TRANSFER  ALL  TO  PRIAS 


**WORKING  HOURS  REQUISITION  GENERATION  (WEEKDAY) ********************** 


GENERATE 

k 

TEST  E 

it 

SPLIT 

k 

DAYAD  ADVANCE 


2400, ,801, , , 8PH 
BV$WKDAY,K1, RQTRM 
V$WRKDD , DAYAD 
437,437 


TRANSFER  , PRIAS 


GENERATE  A  SINGLE  TRANSACTION  AT 
0801  EACH  DAY 

TRANSFER  TO  NEXT  BLOCK  IF  A 
WORKDAY,  ELSE  TO  RQTRM 
SPLIT  TRANSACTION  INTO  THE  NUMBER 
OF  REQS  REC'D  DURING  WORKDAY 
SPREAD  REQUISITION  FLOW  UNIFORMLY 
THROUGHOUT  WORKDAY 
TRANSFER  ALL  TO  PRIAS 


**PM  REQUISITION  GENERATION  (WEEKDAY) ********************************* 


GENERATE  2400 ,, 1676 ,,, 8PH 


TEST  E 

lc 

SPLIT 

it 

PMAD  ADVANCE 


BV$WKDAY,K1, RQTRM 

V$PMDD,PMAD 

362,362 


TRANSFER  , PRIAS 


GENERATE  A  SINGLE  TRANSACTION  AT 
1646  EACH  DAY 

TRANSFER  TO  NEXT  BLOCK  IF  ON  A 
WORKDAY,  ELSE  TO  RQTRM 
SPLIT  TRANSACTION  INTO  THE  NUMBER 
OF  REQS  REC'D  DURING  WORKDAY  PM 
SPREAD  REQUISITION  FLOW  UNIFORMLY 
THROUGHOUT  WORKDAY  PM 
TRANSFER  ALL  TO  PRIAS 
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* "WEEKEND  REQUISITION  GENERATION******************************** 


GENERATE  2400 8PH 


TEST  E 

*r 

SPLIT 

k 

WKDAD  ADVANCE 


BV$WKDAY , KO , RQTRM 
V$DDMND, WKDAD 
1200,1200 


TRANSFER  ,PRIAS 

■k 

RQTRM  TERMINATE 

**PRIORITY  ASSIGNMENT  AND  STATISTICS 

k 


PRIAS  ASSIGN 

PRIORITY 


1 , FNSFONE 
PI 


SAVEVALUE  REQCT+,1,XF 
SAVEVALl/E  REQCT+,1,XF 


SAVEVALUE 
TEST  NE 

TEST  G 


REQCT+ ,  1 ,  XF 
PI  ,1  ,CNTTH 

PI , 5 , CNTTW 


SAVEVALUE  PRION+,l,XF 
SAVEVALUE  PRION+,l,XF 


SAVEVALUE 

TRANSFER 

it 

CNTTW  SAVEVALUE 
SAVEVALUE 
SAVEVALUE 
TRANSFER 

k 

CNTTH  SAVEVALUE 
SAVEVALUE 
SAVEVALUE 


PRION+ , 1 ,XF 
, RECPT 

PRITW+ , 1 , XF 
PRITW+ , 1 , XF 
PRITW+ , 1 , XF 
, RECPT 

PRITH+ , 1 , XF 
PRITH+ , 1 , XF 
PRITH+ , 1 , XF 


GENERATE  A  SINGLE  TRANSACTION  AT 
0001  EACH  DAY 

TRANSFER  TO  NEXT  BLOCK  IF  ON  A 
WEEKEND,  ELSE  TO  RQTRM 
SPLIT  TRANSACTION  INTO  THE  NUMBER 
OF  REQS  REC'D  DURING  WEEKEND  DAY 
SPREAD  REQUISITION  FLOW  UNIFORMLY 
THROUGHOUT  WORKDAY  PM 
TRANSFER  ALL  TO  PRIAS 

TERMINATE  DISCARDED  TRANSACTIONS 
SECTION*****^******************** 

ASSIGNMENT  OF  REO  PRIORITY  TO  PI 

ASSIGNMENT  OF  ACfUAL  TRANSACTION 

PRIORITY  (MATCHES  PI  ASSIGN.) 

COUNTS  TOTAL  NO  OF  REQS  GENERATED 

COUNTS  TOTAL  NO  OF  REQS  GENERATED 

COUNTS  TOTAL  NO  OF  REQS  GENERATED 

SEND  IPG3  REQS  TO  CNTTH,  ALL 

OTHERS  TO  NEXT  BLOCK 

SEND  IPG2  REQS  TO  CNTTW,  ALL 

OTHERS  TO  NEXT  BLOCK 

COUNT  IPG1  REQS 

COUNT  IPG1  REOS 

COUNT  IPG1  REQS 

TRANSFER  ALL  TO  RECPT 

COUNT  IPG2  REQS 
COUNT  IPG2  REQS 
COUNT  IPG2  REQS 
TRANSFER  ALL  TO  RECPT 

COUNT  IPG3  REQS 
COUNT  IPG3  REQS 
COUNT  IPG3  REQS 


********************************************************************** 
**  REQUISITION  RECEIPT  ** 

**  THE  SOURCE  OF  EACH  REQ  ENTERING  SYSTEM  IS  DETERMINED.  ONLINE  REQS** 
**  ARE  SENT  TO  THE  CPU  TEST  MODULE,  9MP,9MB,1Q  REQS  TO  SKCKQ  FOR  ** 
**  STOCK  CHECK  AND  OTHER  HARD  COPY  REQS  TO  THE  NSD  REMOTE  TERMINAL  ** 
**  ENTRY  MODULE.  AFTER  9MP,9MB,1Q  REQS  ARE  STOCK  CHECKED,  NIS  REQS  ** 
**  ARE  TERMINATED.  ALL  OTHERS  ARE  TAGGED  AS  IN  STOCK  AND  SENT  TO  ** 
**  SENT  TO  THE  NSD  REMOTE  TERMINAL  ENTRY  MODULE.  ** 

********************************************* ************************* 


**  NOTE :  ** 
**  NON-WORK  HOUR  TRANSACTION  HANDLING  IS  MANAGED  THROUGHOUT  THE  ** 
**  PROGRAM  BY  CODE  SEGMENTS  SIMILAR  TO  THAT  SEPARATED  BELOW  BY  ** 
**  ASTERISKS.  THE  FIRST  THREE  TEST  STATEMENTS  LINK  TRANSACTIONS  TO  ** 
**  THE  NAMED  USER  CHAIN  1)  DURING  LUNCH;  2)  DURING  WORKING  HOURS  ** 
**  IF  THE  STORAGE  IS  FULL;  3)  AFTER  WORKING  HOURS  EXCEPT  FOR  HIGH  ** 
**  PRIORITY  TRANSACTIONS  (Pl=4,5,6,7)  WHICH  ARE  ASSIGNED  A  PROGRESS  ** 
**  PARAMETER,  REMOVED  FROM  THE  QUEUE  AND  TRANSFERRED  TO  THE  DUTY  ** 
**  SECTION  MODULE.  TRANSACTIONS  ARE  UNLINKED  FROM  THE  USER  CHAIN  TO  ** 
**  THE  STORAGE  ENTER  BLOCK  AT  THE  BEGINNING  OF  THE  WORKDAY  AND  AFTER** 
**  LUNCH  TO  INITIALLY  FILL  THE  STORAGE.  TRANSACTIONS  ARE  UNLINKED  ** 
**  AT  THE  END  OF  THE  WORKDAY,  SO  THAT  HIGH  PRIORITY  TRANSACTIONS  ** 
**  MAY  BE  TRANSFERRED  TO  THE  DUTY  SECTION  MODULE  (LOW  PRIORITY  ** 
**  TRANSACTIONS  ARE  RELINKED).  FINALLY  TRANSACTIONS  ARE  UNLINKED  ** 
**  TO  THE  STORAGE  ENTER  BLOCK  ON  A  ONE  FOR  ONE  BASIS  WITH  ** 
**  TRANSACTIONS  LEAVING  THE  STORAGE.  THIS  SECTION  OF  CODE  APPEARS  ** 
**  IN  MOST  MODULES  CONTAINING  STORAGES,  AND  WILL  NOT  BE  COMMENTED  ** 
**  ON  EXCEPT  AS  IT  DIFFERS  FROM  THE  STANDARD  FORMAT.  ** 
********************************************************************** 


RECPT  TRANSFER 

k 

TRANSFER 

k 

TRANSFER 


. V$ONLIN , ,NISTE 
. V$RQDIV , , SKCKQ 
.V$GROSS, , RTETE 


SKCKQ 

**FLOW 


ASSIGN 
TRANSFER 
QUEUE 
CONTROL 
TEST  E 

TEST  E 

TEST  E 


6  ,K1 
, RTETE 
QSKCK. 3 

SEGMENT*’'******* 

BV$LUNCH, KO , SKCKL 

BV$WORKH , K1 , SKCKT 

R$SKCK , KO , SKCKE 


SEND  ONLINE  REQS  TO  NIS  TEST, 

HARD  COPY  REQS  TO  NEXT  BLOCK 

SEND  IQ , 9MP , 9MB  TO  SKCKQ,  ALL 

OTHERS  TO  NEXT  BLOCK 

SEND  NIS  REQS  TO  NEXT  BLOCK,  ALL 

OTHERS  TO  RTETE 

TAG  NIS  REQS 

TRANSFER  ALL  TO  RTETE 


SKCKL  LINK 
SKCKT  TEST 


GE 


ASSIGN 
DEPART 
TRANSFER 
SKCKA  ADVANCE 
TRANSFER 


**************************************** 
SEND  ALL  TO  SKCKL  DURING  LUNCH, 
ELSE  NEXT  BLOCK 
SEND  ALL  TO  NEXT  BLOCK  DURING 
WORKING  HOURS,  ELSE  SEND  TO  SKCKT 
SEND  ALL  TO  SKCKE  IF  STORAGE  IS 
NOT  FULL,  ELSE  NEXT  BLOCK 
SKCKC , 1PH  LINK  TO  USER  CHAIN  SKCKC 

PI, K4, SKCKA  SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  SKCKA 

3 , KO  ASSIGN  PROGRESS  PARAMETER 

QSKCK , 3  REMOVE  FROM  QSKCK 

, DUTSC  SEND  HI  PRI  REQS  TO  DUTSC 

1  DUMMY 

, SKCKL  SEND  ALL  TO  SKCKL 


**emd  of  flow  control  segment****************************************** 


SKCKE 

ENTER 

SKCK 

SKCKD 

DEPART 

QSKCK, 3 

SKCK 

ADVANCE 

VSSKCKS 

STOCK  CHECK  ON  9MP,9MB,9Q 

SKCKV 

LEAVE 

SKCK 

* 

TEST  E 

BV$WORKH,Kl, NISTR 

DURING  WORKING  HOURS,  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  NISTR 

* 

UNLINK 

SKCKC, SKCKE, 1, BACK 

RELEASE  ONE  TRANSACTION  FROM  SKCKC 

NISTR 

* 

TRANSFER 

. V$GROSS ,NISTM , ISTAG 

SEND  NIS  REQUISITIONS  TO  NISTM , 

ALL  OTHERS  TO  ISTAG 

I  STAG 

* 

ASSIGN 

6  ,K2 

TAG  STOCKED  CHECKED  REQS 

FOUND  IN  STOCK 

TRANSFER 

, CRTEQ 

TRANSFER  ALL  TO  CRTEQ 
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*********** *********** *** ******************** ***************** A** A** ** 

**  NSD  REMOTE  TERMINAL  ENTRY  ** 
**  9MP , 9MB , 10  AND  ALL  REQS  (PI  =  3, 4, 5, 6, 7)  ENTERED  VIA  OUST  SERV  ** 
**  RTE ,  REQS  (PI  =  1,2)  ARE  ENTERED  VIA  DPSC  RTE .  MIS  REQS  ARE  ** 
**  TRANSFERRED  TO  TERMINATION  AND  ALL  OTHERS  ARE  SENT  TO  THE  CPU  ** 
**  CPU  TEST  MODULE.  ** 
********************************************************************** 
* 


^RTETE  TEST  GE  PI ,K3 ,DRTEQ 


* 

* 


**CUSTOMER  SERVICES  REMOTE  TERMINAL 
* 


SEND  IPG3  AND  NON  1Q,9MB,9MP  IPG2 
REQS  TO  DRTEQ ,  ALL  OTHERS  TO  NEXT 
BLOCK 

ENTRY***************************** 


CRTEQ 

QUEUE 

QCRTE , 3 

TEST  E 

BV$LUNCH,KO, CRTEL 

SEND  ALL  TO  CRTEL  DURING  LUNCH, 

* 

TEST  E 

BV$W0RKH,K1, CRTET 

ELSE  NEXT  BLOCK 

SEND  ALL  TO  NEXT  BLOCK  DURING 

* 

TEST  E 

WORKING  HOURS,  ELSE  SEND  TO  CRTET 
SEND  ALL  TO  CRTEE  IF  STORAGE  IS 

R$CRTE,KO, CRTEE 

* 

NOT  FULL,  ELSE  NEXT  BLOCK 

CRTEL 

LINK 

CRTEC , 1PH 

LINK  TO  USER  CHAIN  CRTEC 

CRTET 

TEST  GE 

PI, K4, CRTEA 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

* 

ALL  OTHERS  TO  CRTEA 

ASSIGN 

3  ,K1 

ASSIGN  PROGRESS  PARAMETER 

DEPART 

QCRTE, 3 

REMOVE  FROM  QCRTE 

TRANSFER 

,  DUTSC 

SEND  HI  PRI  REQS  TO  DUTSC 

CRTEA 

ADVANCE 

1 

DUMMY 

TRANSFER 

, CRTEL 

SEND  ALL  TO  CRTEL 

CRTEE 

ENTER 

CRTE 

DEPART 

QCRTE , 3 

CRTE 

ADVANCE 

VSRTES 

ENTER  REQS  VIA  CUST  SERV  RTE 

LEAVE 

CRTE 

TEST  E 

BV$WORKH , K1 , CSTR 

* 

UNLINK 

CRTEC, CRTEE, 1, BACK 

RELEASE  ONE  TRANSACTION  FROM  CTWO 

CSTR 

TEST  E 

P6 , 1 , PRTE 

SEND  NIS  REQS  TO  NEXT  BLOCK,  ALL 

* 

OTHER  TO  PRTE 

* 

TRANSFER 

, NISTM 

TRANSFER  NIS  REQS  TO  NISTM 

**DPSC 

* 

REMOTE  TERMINAL  ENTRY*****************  ******  ***********  ********* 

DRTEQ 

QUEUE 

TEST  E 

QDRTE , 3 

BV$W0RKH,K1 , DRTEL 

SEND  ALL  TO  NEXT  BLOCK  DURING 

* 

TEST  E 

WORKING  HOURS,  ELSE  SEND  TO  DRTEL 
SEND  ALL  TO  DRTEE  IF  STORAGE  IS 

R$DRTE,KO, DRTEE 

* 

NOT  FULL,  ELSE  NEXT  BLOCK 

DRTEL 

LINK 

DRTEC , 1PH 

LINK  TO  USER  CHAIN  DRTEC 

DRTEE 

ENTER 

DRTE 

DEPART 

QDRTE, 3 

DRTE 

ADVANCE 

VSRTES 

ENTER  REQS  VIA  DPSC  RTE 

LEAVE 

DRTE 

TEST  E 

BVSWORKH , K1 , DPTE 

* 

UNLINK 

DRTEC, DRTEE, 1, BACK 

RELEASE  ONE  TRANSACTION  FROM  DRTEC 

DPTE 

TEST  E 

P6 , 1 ,PRTE 

SEND  NIS  REOS  TO  NEXT  BLOCK,  ALL 

* 

OTHER  TO  PRINTER  TEST 

TRANSFER 

, NISTM 

TRANSFER  NIS  REQS  TO  NISTM 
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************************ ********* * ****** ****************************** 
**  CPU  TESTS  ** 

**  TEST  FOR,  PROCESS  AND  RE-ENTER  DEMAND  EXCEPTIONS.  TEST  FOR  AND  ** 
**  TRANSFER  ONLINE  NIS  REQS .  ROUTE  IPG3  AND  NON  9MP,9MB,9MF  AND  10  ** 
**  IPG2  REQS  TO  STOR  CONT  PRINTER,  BALANCE  TO  CUST  SERV  PRINTER  IN  ** 
**  THE  PRINTER  QUEUE  HANDLING  MODULE.  ** 

***************x********* ****** *************************************** 
* 


NISTE  TRANSFER 


. V$GROSS ,NISTM , PRTE  SEND  NIS  REQS  TO  NISTM,  ALL 

OTHERS  TO  PRTE 


PRTE  TEST  L 


TRANSFER 


PI ,K3 , CSPRQ 


SEND  REQS  (PI  =  3, 4, 5, 6, 7)  TO 
CSPRQ,  ALL  OTHERS  TO  NEXT  BLOCK 


•V$PROV,SCPRQ, CSPRQ  SEND  9MF , 9MP , 9MB , IQ  REQS  TO 

CSPRQ,  ALL  OTHERS  TO  SCPRQ 


************************* ************ ********************** ** ******** A 


** 


** 

** 


PRINTER  QUEUE  HANDLING 

**  LINK  IPG3  REQS  ON  USER  CHAIN  THREE,  UNLINK  THEM  TO  PRINT  ISSUE 
**  DOCUMENTS  IN  STORAGE  CONTROL  AT  0800  ON  WORKDAYS.  LINK  IPG2  REQS  ** 
**  ON  USER  CHAIN  TWO,  UNLINK  THEM  TO  PRINT  ISSUE  DOCUMENTS  IN 
**  STORAGE  CONTROL  AT  0800,1000,1245,1445  ON  WORKDAYS.  LINK  ALL 
**  IPG1 , BWT , CASREPT , QUICK  PICK , 9MF , 9MP , 9MB , IQ  REQS  ON  USER  CHAIN 
**  ONE,  UNLINK  TO  PRINT  ISSUE  DOCUMENTS  ON  THE  CUST  SERV  PRINTER 
**  EVERY  FIVE  MINUTES.  ALL  ISSUE  DOCS  PRINTED  ALL  SENT  TO  THE 
**  DEMAND  EXCEPTION  HANDLING  MODULE.  PRINTER  OPERATIONS  ARE 
**  MODELED  BY  THE  CONTROL  TRANSACTION  IN  THE  PARTIONED  SCHEDULE 
**  CONTROL  SECTION. 
********************************************************************** 


** 

** 

** 

** 

** 

** 

** 

** 


**PRINTER  CONTROL  SECTION* ****** ****************************** ********* 
* 


GENERATE 

UNLINK 


25 


GENERATE  CONTROL  TRANSACTION  TO 
TRIGGER  PRINTER  EVERY  15  MIN 


THREE, SCPRE, ALL, BV$PRTHR 

SEND  ALL  REQS  ON  USER  CHAIN  THREE 
TO  THE  STORAGE  CONTROL  PRINTER 


* 

* 

* 

UNLINK 

TWO , SCPRE , ALL , BV$PRTW0 

SEND  ALL  REOS  ON  USER  CHAIN  TWO 
TO  THE  STORAGE  CONTROL  PRINTER 

* 

TERMINATE 

TERMINATE  CONTROL  TRANSACTION 

* 

* 

* 

GENERATE 

5 

GENERATE  CONTROL  TRANSACTION  TO 
TRIGGER  CUdT  SERV  PRINTER  EVERY 

5  MINUTES 

UNLNK 

* 

* 

UNLINK 

ONE, CSPRE, ALL, BACK 

SEND  ALL  REQS  ON  USER  CHAIN  ONE 
TO  THE  CUST  SERV  PRINTER 

* 

TERMINATE 

TERMINATE  CONTROL  TRANSACTION 

**STORAGE  CONTROL 
* 

PRINTER  OPERATIONS 

SECTION*************************** 

SCPRQ  QUEUE 

* 

QSCPR, 3 

ENTER  STORAGE  CONT  PRINTER  QUEUE 

* 

* 

TEST  E 

P1,K1, LKTWO 

SEND  IPG2  REQS  TO  LKTWO, 

IPG3  TO  NEXT  BLOCK 

LKTWO 

* 

LINK 

LINK 

THREE, 1PH 

TWO , 1PH 

LINK  IPG3  ON  USER  CHAIN  THREE 
LINK  IPG2  ON  USER  CHAIN  TWO 

SCPRE 

SCPR 

* 

ENTER 

DEPART 

ADVANCE 

LEAVE 

SCPR 

QSCPR, 3 

SCPR 

DEPART  QUEUE 

PRINT  ISSUE  DOCS 

* 

TRANSFER 

,DEXTE 

TRANSFER  ALL  TO  DEXTE 

**CUSTOMER  SERVICES  PRINTER  OPERATIONS  SECTION************************* 
* 

^CSPRQ 

QUEUE 

QCSPR , 3 

ENTER  CUST  SERV  PRINTER  QUEUE 

* 

LINK 

ONE, 1 PH 

LINK  ALL  TO  USER  CHAIN  ONE 

CSPRE 

CSPR 

ENTER 

DEPART 

ADVANCE 

LEAVE 

CSPR 

QCSPR, 3 

CSPR 

DEPART  QUEUE 

PRINT  ISSUE  DOCS 

★★★★★A******************************** ******************************** 

**  DEMAND  EXCEPTION  HANDLING  ** 
**  TRANSACTIONS  ARE  RECEIVED  FROM  THE  PRINTER  QUEUE  HANDLING  MODULE  ** 
**  AND  THE  WAREHOUSE  MODULE.  PREVIOUSLY  PROCESSED  DEMAND  EXCEPTIONS  ** 
**  ARE  SENT  TO  THE  WAREHOUSE  ASSIGNMENT  MODULE,  WAREHOUSE  REFUSALS  ** 
**  ARE  PROCESSED  AS  SUCH  AND  TERMINATED.  NEW  DEMAND  EXCEPTIONS  ARE  ** 
**  PROCESSED,  TAGGED  AS  COMPLETED  AND  SENT  BACK  TO  THE  PRINTER  ** 
**  QUEUE  HANDLING  MODULE.  TRANSACTIONS  NOT  RESULTING  IN  DEMAND  ** 
**  EXCEPTIONS  ARE  SENT  DIRECTLY  TO  THE  WAREHOUSE  ASSIGNMENT  MODULE.  ** 
********************************************************************** 
* 


* 

* 

* 


* 

* 

* 


* 

* 


* 


* 

* 


DEXTE 

TEST  NE 

P7,K1, LOCAS 

TRANSFER 

. VSNOTEX, , LOCAS 

DEEXQ 

QUEUE 

QDEEX, 3 

TEST  E 

BV$LUNCH,KO, DEEXL 

TEST  E 

BV$WORKH,Kl, DEEXT 

TEST  E 

R$DEEX,K0, DEEXE 

DEEXL 

LINK 

DEEXC, 1PH 

DEEXT 

TEST  GE 

PI, K4, DEEXA 

TEST  NE 

P8,K1, DEEXA 

ASSIGN 

3  ,K3 

DEPART 

QDEEX, 3 

TRANSFER 

,  DUTSC 

DEEXA 

ADVANCE 

1 

TRANSFER 

, DEEXL 

DEEXE 

ENTER 

DEEX 

DEPART 

QDEEX, 3 

DEEX 

ADVANCE 

V5DEEXS 

LEAVE 

DEEX 

ASSIGN 

7  ,K1 

TEST  E 

BV$WORKH,Kl ,WRTE 

UNLINK 

DEEXC, DEEXE, Kl, BACK 

WRTE 

TEST  E 

P3 , K1 , PRTE 

SEND  PROCESSED  DEMAND  EXCEPTIONS 
TO  LOCAS,  OTHERS  TO  NEXT  BLOCK 
SEND  REQS  WITH  DEMAND  EXCEPTIONS 
TO  NEXT  BLOCK,  SEND  OTHERS  TO 
LOCAS 

SEND  ALL  TO  DEEXL  DURING  LUNCH, 

ELSE  NEXT  BLOCK 

SEND  ALL  TO  NEXT  BLOCK  DURING 

WORKING  HOURS,  ELSE  SEND  TO  DEEXT 

SEND  ALL  TO  DEEXE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

LINK  TO  USER  CHAIN  DEEXC 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  DEEXA 

SEND  WAREHOUSE  REFUSALS  TO  DEEXA, 

ALL  OTHERS  TO  NEXT  BLOCK 

ASSIGN  PROGRESS  PARAMETER 

REMOVE  FROM  QDEEX 

SEND  HI  PRI  REQS  TO  DUTSC 

DUMMY 

SEND  ALL  TO  DEEXL 

REMOVE  FROM  USER  CHAIN  QDEEX 
PROCESS  DEMAND  EXCEPT. /WAR.  REF. 

TAG  PROCESSED  DEMAND  EXCEPTIONS 
DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  WRTE 
RELEASE  ONE  TRANSACTION  FROM  DEEXC 
SEND  WAREHOUSE  REFUSALS  TO  NEXT 
BLOCK,  ALL  OTHERS  TO  PRTE 


TRANSFER  , WRTRM  TRANSFER  ALL  TO  WRTRM 
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**;k:fr:fc**x***:fr:fc:k:fexx;k:fc*:krt:kx;*:k*:fr:fr;krtycxx*:fr***x*xx****xxxx***xxx*xx***rtrtxxxx* 

**  WAREHOUSE  ASSIGNMENT  MODULE  ** 

**  ALL  ISSUE  DOCUMENTS  ARE  ASSIGNED  A  WAREHOUSE  LOCATION.  THOSE  ** 

**  ISSUE  DOCUMENTS  IDENTIFIED  AS  WAREHOUSE  REFUSALS  ARE  TAGGED  AS  ** 

**  SUCH.  BEARER  WALKTHROUGH  ISSUE  DOCS  ARE  TAGGED  AND  ARE  ** 

**  TRANSFERRED  TO  THE  WAREHOUSE  MODULE  WITH  A  DELAY  ASSIGNED  BY  ** 

**  LOCATION.  ALL  OTHER  ISSUE  DOCUMENTS  ARE  SENT  TO  THE  STORAGE  ** 

**  OFFICE/STORAGE  CONTROL  MODULE.  ** 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk  kk  A************  *******  A********;*:******  kk 
k 


LOCAS  ASSIGN 


2,FN$FTWO 


TRANSFER  . V$NOTWR , , DESTE 

k 

ASSIGN  8 ,K1 

DESTE  TEST  NE  PI ,K5, BWTAD 


TEST  NE  PI (K7 ,BWTAD 


ASSIGN  WAREHOUSE  LOCATION  TO  P2 

SEND  WAREHOUSE  REFUSALS  TO  NEXT 
BLOCK,  ALL  OTHERS  TO  DESTE 
TAG  WAREHOUSE  REFUSALS 

SEND  IPG2  BWT  TO  BWTAD , 

ALL  OTHERS  TO  NEXT  BLOCK 

SEND  IPG1  BWT  TO  BWTAD, 

ALL  OTHERS  TO  NEXT  BLOCK 


TEST  G 


P2 ,K3 , STOFQ 


SEND  PROV.  REQS  TO  STORAGE  OFF, 
ALL  OTHERS  TO  NEXT  BLOCK 


TRANSFER  ,SCNTQ 


BWTAD  ADVANCE 


FNSFTHSV 


TRANSFER  ALL  TO  SCNTQ 

DELAY  TO  SIMULATE  BEARER 
TRANSPORTATION  TO  THE  WAREHOUSE 


TRANSFER  FN , FTHTW 


SENT  ALL  TO  RESPECTIVE  WAREHOUSE 
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P  pipjp.  A'VJPJ  A  ^^«r:vjv-jy;t-.'^  -t; 


fc;*********:****;*;**:*;********************************:*:*;*****:************* 

**  STORAGE  CONTROL/STORAGE  OFFICE  ** 

**  PROVISIONS  ISSUE  DOCUMENTS  ENTER  AT  STOFQ,  ALL  OTHERS  AT  SCNTQ.  ** 
**  ISSUE  DOCUMENTS  ARE  MARKED,  BURST  AND  SORTED  BY  LOCATION.  ALL  ** 
**  ISSUE  DOCUMENTS  EXCEPT  THOSE  BOUND  FOR  YOKOHAMA  COLD  STORAGE  ARE  ** 
**  SENT  TO  THE  BIKE  MESSENGER  DELIVERY  MODULE.  YOKOHAMA  ISSUE  DOCS  ** 
**  ARE  SENT  TO  THE  YOKOHAMA  ISSUE  DOCUMENT  DELIVERY  MODULE.  ** 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkk  *  *****  ************  A****  ******  *********  *** 


k 

**STORAGE  CONTROL  SECTION*******^************************************* 

•k 


SCNTQ 

QUEUE 

QSCNT,3 

k 

TEST  E 

BV$LUNCH,KO, SCNTL 

SEND  ALL  TO  SCNTL  DURING  LUNCH, 
ELSE  NEXT  BLOCK 

k 

TEST  E 

BV$WORKH,Kl, SCNTT 

SEND  ALL  TO  NEXT  BLOCK  DURING 
WORKING  HOURS,  ELSE  SEND  TO  SCNTT 

k 

TEST  E 

R$SCNT,K0, SCNTE 

SEND  ALL  TO  SCNTE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

SCNTL 

LINK 

SCNTC , 1PH 

LINK  TO  USER  CHAIN  SCNTC 

SCNTT 

* 

TEST  GE 

PI ,K4, SCNTA 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  SCNTA 

ASSIGN 

3 ,  K4 

ASSIGN  PROGRESS  PARAMETER 

DEPART 

QSCNT , 3 

REMOVE  FROM  QSCNT 

TRANSFER 

, DUTSC 

SEND  HI  PRI  REQS  TO  DUTSC 

SCNTA 

ADVANCE 

1 

DUMMY 

TRANSFER 

,  SCNTL 

SEND  ALL  TO  SCNTL 

SCNTE 

ENTER 

DEPART 

SCNT 

QSCNT ,3 

SCNT 

ADVANCE 

LEAVE 

V$SCSOS 

SCNT 

MARK, BURST, SORT  ISSUE  DOCS 

* 

TEST  E 

BV$WORKH,Kl ,SCTE 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  SCTE 

k 

UNLINK 

SCNTC, SCNTE, 1, BACK 

RELEASE  ONE  TRANSACTION  FROM  SCNTC 

SCTE 

■ie 

TRANSFER 

,BIKEQ 

SEND  ALL  TO  BIKEQ 

** STORAGE  OFFICE  SECTION********************************************* 

k 


STOFQ 

QUEUE 

QSTOF , 3 

TEST  E 

BV$LUNCH,KO, STOFL 

SEND  ALL  TO  STOFL  DURING  LUNCH, 
ELSE  NEXT  BLOCK 

TEST  E 

BV$WORKH,Kl, STOFT 

SEND  ALL  TO  NEXT  BLOCK  DURING 
WORKING  HOURS,  ELSE  SEND  TO  STOFT 

TEST  E 

R$STOF,KO, STOFE 

SEND  ALL  TO  STOFE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

STOFL 

LINK 

STOFC , 1PH 

LINK  TO  USER  CHAIN  STOFC 

STOFT 

TEST  GE 

PI, K4, STOFA 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  STOFA 

ASSIGN 

3 ,  K5 

ASSIGN  PROGRESS  PARAMETER 

DEPART 

QSTOF, 3 

REMOVE  FROM  QSTOF 

TRANSFER 

, DUTSC 

SEND  HI  PRI  REQS  TO  DUTSC 

STOFA 

ADVANCE 

1 

DUMMY 

TRANSFER 

, STOFL 

SEND  ALL  TO  STOFL 

STOFE 

ENTER 

STOF 

DEPART 

QSTOF, 3 

REMOVE  FROM  QSTOF 

STOF 

ADVANCE 

LEAVE 

VSSCSOS 

STOF 

MARK, BURST, SORT  ISSUE  DOCS 

TEST  E 

BV$WORKH , K1 , SOTE 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  SOTE 

UNLINK 

STOFC, STOFE, 1, BACK 

RELEASE  ONE  TRANSACTION  FROM  STOFC 

SOTE 

TEST  E 

P2,K1, BIKEQ 

SEND  YOKOHAMA  CS  DOCS  TO  NEXT 
BLOCK,  SEND  ALL  OTHERS  TO  BIKEQ 

TRANSFER 

, DLVRT 

SEND  ALL  TO  DLVRT 
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Ik***********************:*******:*****************:***:******************* 

**  YOKOHAMA  ISSUE  DOCUMENT  DELIVERY  ** 

**  DELIVERY  OF  ISSUE  DOCUMENTS  BY  PICKUP  TRUCK  IS  SIMULATED  IN  THIS  ** 
**  MODULE.  ISSUE  DOCS  ARRIVING  ARE  PLACED  ON  USER  CHAIN  DLVRC  WHICH  ** 
**  IS  UNLINKED  TO  YMCSQ  WITH  AN  APPROPRIATE  TIME  DELAY  AT  0830  ON  ** 
**  WORKDAYS.  BECAUSE  DURING  ACTUAL  OPERATIONS,  HIGH  PRIORITY  ISSUE  ** 
**  DOCUMENTS  ARRIVING  AFTER  0830  ARE  NOT  DELAYED  UNTIL  THE  NEXT  DAY,** 
**  THOSE  HIGH  PRIORITY  DOCUMENTS  ARRIVING  DURING  THE  WORKDAY  AFTER  ** 
**  0830  ARE  TRANSFERRED  DIRECTLY  TO  YMCSQ  TO  AVOID  UNREALISTIC  ** 

**  DELAYS  ON  THE  DLVRC  USER  CHAIN.  HIGH  PRIORITY  ISSUE  DOCUMENTS  ** 
**  ARRIVING  AFTER  WORKING  HOURS  OR  ON  WEEKENDS  ARE  TRANSFERRED  TO  ** 
**  THE  DUTY  SECTION  MODULE.  PICKUP  DELIVERY  OPERATION  SCHEDULING  IS  ** 
**  CONTROLLED  BY  THE  PARTIONED  SCHEDULE  CONTROL  SECTION.  ** 

* 

**SCHEDULE  CONTROL  SECTION********************************************* 
* 

2400,, 850  GENERATE  CONTROL  TRANSACTION  TO 

TRIGGER  YOKOHAMA  DELIVERY 
DLVRC , DLVRE , ALL , BV$WKDAY 

SEND  ISSUE  DOCS  ON  DELIVER  USER 
CHAIN  TO  DLVRE 

TERMINATE  TERMINATE  CONTROL  TRANSACTION  . 

k 

**OPERATIONS  SECTION**************************************************- 

k 

DLVRT  TEST  G 

k 

TEST  E 

* 

TEST  G 

k 

TRANSFER 
k 

DLVTR  ASSIGN 

TRANSFER 

k 

DLVRQ  QUEUE  QDLVR,3  ENTER  QUEUE  FOR  REQ  DELIVERY 

*  TO  YOKOHAMA  CS 

k 

DLVRL  LINK  DLVRC, 1PH  WAIT  ON  USER  CHAIN  DLVRC 

* 

DLVRE  ENTER  DLVR 

DEPART  QDLVR , 3 

DLVR  ADVANCE  150,50 

LEAVE  DLVR 

k 

TRANSFER  , YMCSQ  TRANSFER  ALL  TO  YOKOHAMA  COLD 

*  STORAGE  QUEUE 


DEPART  QUEUE 
DELIVERY  TO  YOKOHAMA 


PI, K3, DLVRQ  SEND  LOW  PRI  ISSUE  DOCS  TO  DLVRQ, 

ALL  OTHERS  TO  NEXT  BLOCK 

BV$0PEN,K1, DLVTR  IF  OUTSIDE  OF  DEPOT  WORKING  HOURS, 

SEND  TO  DLVTR,  ELSE  NEXT  BLOCK 
V$TIME,K0850, DLVRQ  IF  AFTER  DAILY  RUN,  SEND  TO  NEXT 

BLOCK,  ELSE  DLVRO 

, YMCSQ  TRANSFER  ALL  TO  YMCSQ 

3 , K6  ASSIGN  PROGRESS  PARAMETER 

, DUTSC  SEND  ALL  TO  DUTSC 


GENERATE 

k 

UNLINK 

k 

k 

k 


★A*********************************** ********************************* 

**  BICYCLE  MESSENGER  DELIVERY  ** 

**  THIS  MODULE  DELIVERS  ISSUE  DOCUMENTS  TO  WAREHOUSE  LOCATIONS  BY  ** 

**  BICYCLE  MESSENGER  AT  0900,1100,1345  AND  1515  ON  WORKDAYS.  HIGH  ** 

**  PRIORITY  REQS  ARRIVING  DURING  WORKING  HOURS  AFTER  THE  LAST  RUN  ** 

**  ARE  TRANSFERRED  TO  THE  WAREHOUSE  MODULE  DIRECTLY  TO  SIMULATE  ** 

**  DELIVERY  BY  OFFICE  PERSONNEL  IN  ACCORDANCE  WITH  ACTUAL  ** 

**  PROCEDURES.  THE  SCHEDULE  CONTROL  SECTION  IS  PARTIONED  IN  THE  ** 

**  TOP  HALF  OF  THE  MODULE.  ** 

********************************************************************** 

* 

*  ^SCHEDULE  CONTROL  SECTION******************************************** 

* 

GENERATE  25  GENERATE  CONTROL  TRANSACTION  TO 

*  TRIGGER  PRINTER  EVERY  15  MIN 

* 

UNLINK  BIKEC,BIKEE,ALL,BV$DTIME 

*  SEND  ALL  ISSUE  DOCS  ON  USER  CHAIN 

*  BIKEC  TO  BIKEQ 

TERMINATE  TERMINATE  CONTROL  TRANSACTION 

* 

^OPERATIONS  SECTION************************************************** 

* 


BIKEQ  QUEUE 

TEST  GE 

TEST  G 

TEST  L 

QBIKE , 3 

PI, K4, BIKEL 

V$TIME,K1525, BIKEL 

V$TIME,K1676, BIKTR 

SEND  LOW  PRI  REQS  TO  BIKEL, 

ALL  OTHERS  TO  NEXT  BLOCK 

IF  BEFORE  LAST  MESSENGER  RUN,  SEND 
ALL  TO  BIKEL,  ELSE  NEXT  BLOCK 

IF  DURING  WORKING  HOURS  SEND  TO 
NEXT  BLOCK,  ELSE  BIKTR 

DEPART 

ADVANCE 

TRANSFER 

QBIKE, 3 

Fnsfthsv 
,  WHTR 

OFFICE  PERSONNEL  DELIVER 

SEND  HI  PRI  REQS  TO  WHTR 

BIKTR 

DEPART 

ASSIGN 

TRANSFER 

QBIKE, 3 

3,K7 
,  DUTSC 

ASSIGN  PROGRESS  PARAMETER 

SEND  HI  PRI  REQS  TO  DUTSC 

BIKEL 

LINK 

BIKEC, 1PH 

LINK  ALL  ISSUE  DOCUMENTS  AWAITING 
TRANSPORTATION  TO  BIKEC 

BIKEE 

BIKE 

ENTER 

DEPART 

ADVANCE 

LEAVE 

BIKE 

QBIKE, 3 

FMSFTH5X 

BIKE 

DELIVER  ISSUE  DOCS  TO  WAREHOUSES 
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********  ******************  *************** 
**  WAREHOUSES  ** 

**  ISSUE  DOCUMENTS  ARE  SENT  TO  THE  WAREHOUSE  INDICATED  BY  P2.  ** 

**  PICKING,  STAGING  AND  SHIPMENT  PREPARATION  (PROVISIONS  WAREHOUSES  ** 
**  ONLY)  FUNCTIONS  ARE  SIMULATED.  WAREHOUSE  REFUSALS  ARE  TRANSFERRED** 
**  TO  THE  DEMAND  EXCEPTION  MODULE  FOR  PROCESSING.  BWT  AND  QUICK  ** 

**  PICK  ISSUES  ARE  TRANSFERRED  TO  TERMINATION  AS  WELL  AS  ISSUES  ** 

**  MADE  AVAILABLE  FOR  SHIPMENT  DIRECTLY  FROM  PROVISIONS  WAREHOUSES.  ** 
**  ISSUES  FROM  YOKOSUKA  COLD  STORAGE  AND  B-47  REQUIRING  PACKING  ** 

**  OR  SHIPMENT  FROM  THE  FREIGHT  TERMINAL  ARE  TRANSFERRED  TO  THE  ** 

**  PROVISIONS  TRACTOR  TRAIN  MODULE.  ALL  OTHER  ISSUES  FROM  GENERAL  ** 
**  STORAGE  LOCATIONS  ARE  SENT  TO  THE  TRACTOR  TRAIN  DELIVERY  MODULE.  ** 
**  WAREHOUSE  SUBMODULES  ARE  PARTIONED  AMD  LABELED.  ** 

* 

WHTR  TRANSFER  FN , FTHTW  TRANSFER  ISSUE  DOCS  TO  STORAGE 

*  LOCATION 

* 


*  YOKOHAMA  COLD  STORAGE******  ******  ****************************  *********** 
k 


YMCSQ 

QUEUE 

QYMCS , 3 

k 

TEST  E 

BV$LUNCH,KO, YMCSL 

SEND  ALL  TO  YMCSL  DURING  LUNCH, 
ELSE  NEXT  BLOCK 

k 

TEST  E 

BV$W0RKH,K1, YMCST 

SEND  ALL  TO  NEXT  BLOCK  DURING 
WORKING  HOURS,  ELSE  SEND  TO  YMCST 

k 

TEST  E 

R$YMCS,K0, YMCSE 

SEND  ALL  TO  YMCSE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

YMCSL 

LINK 

YMCSC , 1PH 

LINK  TO  USER  CHAIN  YMCSC 

YMCST 

k 

TEST  GE 

P1,K4, YMCSA 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  YMCSA 

ASSIGN 

3 ,  K8 

ASSIGN  PROGRESS  PARAMETER 

DEPART 

QYMCS , 3 

REMOVE  FROM  QYMCS 

TRANSFER 

, DUTSC 

SEND  HI  PRI  REQS  TO  DUTSC 

YMCSA 

ADVANCE 

1 

DUMMY 

TRANSFER 

, YMCSL 

SEND  ALL  TO  YMCSL 

YMCSE 

ENTER 

DEPART 

YMCS 

QYMCS , 3 

YMCS 

ADVANCE 

LEAVE 

VSYMCSS 

YMCS 

PICK,  PREPARE  FOR  SHIP  AND  STAGE 

* 

TEST  E 

BV$W0RKH,K1 ,YMTE 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  YMTE 

X 

UNLINK 

YMCSC, YMCSE, 1, BACK 

RELEASE  ONE  TRANSACTION  FROM  YMCSC 

YMTE 

k 

k 

TEST  NE 

P8 , K1 , DEEXQ 

SEND  WAREHOUSE  REFUSALS  TO 
EXCEPTION  HANDLING 

k 

TRANSFER 

,  TERM 

TERMINATE  REQS  AVAILABLE  FOR 
SHIPMENT 
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*  *  *  X  X  XX  XX 


** YOKOSUKA  COLD  STORAGE** ****** ****************************************** 


YKCSQ 

QUEUE 

QYKCS , 3 

k 

TEST  E 

BV$LUNCH,KO, YKCSL 

SEND  ALL  TO  YKCSL  DURING  LUNCH, 
ELSE  NEXT  BLOCK 

k 

TEST  E 

BV$WORKH,Kl, YKCST 

SEND  ALL  TO  NEXT  BLOCK  DURING 
WORKING  HOURS,  ELSE  SEND  TO  YMCST 

k 

TEST  E 

R$YKCS,K0, YKCSE 

SEND  ALL  TO  YKCSE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

YKCSL 

LINK 

YKCSC , 1PH 

LINK  TO  USER  CHAIN  YKCSC 

YKCST 

k 

TEST  GE 

PI ,K4 , YKCSA 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  YKCSA 

ASSIGN 

3 ,  K9 

ASSIGN  PROGRESS  PARAMETER 

DEPART 

QYKCS, 3 

REMOVE  FROM  QYKCS 

TRANSFER 

,  DUTSC 

SEND  HI  PRI  REQS  TO  DUTSC 

YKCSA 

ADVANCE 

1 

DUMMY 

TRANSFER 

, YKCSL 

SEND  ALL  TO  YKCSL 

YKCSE 

ENTER 

DEPART 

YKCS 

QYKCS ,3 

YKCS 

ADVANCE 

LEAVE 

VSYKCSS 

YKCS 

PICK  AND  STAGE  MATERIAL 

k 

TEST  E 

BV$WORKH,Kl , YKTE 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  YKTE 

k 

UNLINK 

YKCSC, YKCSE, 1, BACK 

RELEASE  ONE  TRANSACTION  FROM  YKCSC 

YKTE 

k 

k 

TEST  NE 

P8 , K1 , DEEXQ 

SEND  WAREHOUSE  REFUSALS  TO 
EXCEPTION  HANDLING 

k 

k 

TEST  E 

BV$BEAR , KO , TERM 

SEND  BEARER  ISSUES  TO  TERM, 

ALL  OTHERS  TO  NEXT  BLOCK 

k 

ASSIGN 

4 , FN$FFOUR 

ASSIGN  ISSUE  DESTINATIONS  TO  P4 

k 

ASSIGN 

5 ,V$YKCSW 

ASSIGN  ISSUE  WEIGHT 

k 

k 

k 

TEST  NE 

P4 , K1 , TERM 

SEND  ISSUES  FOR  PACKING  OR  FREIGHT 
TERMINAL  SECTION  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  TERM 

TRANSFER 

, PTRNQ 

TRANSFER  ALL  TO  PTRNQ 

ai 


*  *  *  * 


**B-47  (DRY  PROVISIONS )  ^^^^k^********************************************* 


DRYWQ  QUEUE  QDRYW , 3 

TEST  E  BV$LUNCH,KO , DRYWL 

* 

TEST  E  BV$W0RKH,K1,DRYWT 

TEST  E  R$DRYW , KO , DRYWE 

DRYWL  LINK  DRYWC, 1PH 

^DRYWT  TEST  GE  PI, K4, DRYWA 

ASSIGN  3 , K10 

DEPART  QDRYW , 3 

TRANSFER  ,DUTSC 

DRYWA  ADVANCF  1 

TRANSFER  , DRYWL 

DRYWE  ENTER  DRYW 

DEPART  QDRYW, 3 

DRYW  ADVANCE  VSDRYWS 

LEAVE  DRYW 

TEST  E  BV$WORKH , K1 ..DRYT 

UNLINK  DRYWC , DRYWE , 1 , BACK 

•k 

DRYT  TEST  NE  P8,K1,DEEXQ 


TEST  E  BV$BEAR , KO , TERM 


ASSIGN  4 , FNSFFIVE 

ASSIGN  5 ,V$DRYWW 

TEST  NE  P4 , K1 , TERM 


TRANSFER  , PTRNQ 


SEND  ALL  TO  DRYWL  DURING  LUNCH, 

ELSE  NEXT  BLOCK 

SEND  ALL  TO  NEXT  BLOCK  DURING 

WORKING  HOURS,  ELSE  SEND  TO  DRYWT 

SEND  ALL  TO  DRYWE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

LINK  TO  USER  CHAIN  DRYWC 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  DRYWA 

ASSIGN  PROGRESS  PARAMETER 

REMOVE  FROM  QDRYW 

SEND  HI  PRI  REQS  TO  DUTSC 

DUMMY 

SEND  ALL  TO  DRYWL 


PICK  AND  STAGE  MATERIAL 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  DRYT 
RELEASE  ONE  TRANSACTION  FROM  DRYWC 

SEND  WAREHOUSE  REFUSALS  TO 
EXCEPTION  HANDLING 

SEND  BEARER  ISSUES  TO  TERM,  ALL 
OTHERS  TO  NEXT  BLOCK 

ASSIGN  ISSUE  DESTINATION 

ASSIGN  ISSUE  WEIGHT 

SEND  ISSUES  FOR  PACKING  OR  FREIGHT 
TERMINAL  SECTION  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  TERM 

TRANSFER  ALL  TO  PTRNQ 
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I 


*A  WAREHOUSE  AREA 
AWHEQ  QUEUE 
TEST  E 

k 

TEST  E 

* 

TEST  E 

* 

AWHEL  LINK 
AWHET  TEST  GE 

k 

ASSIGN 
DEPART 
TRANSFER 
AWHEA  ADVANCE 
TRANSFER 
AWHEE  ENTER 
DEPART 

AWHE  ADVANCE 
LEAVE 
TEST  E 

k 

UNLINK 


(  A~19  )  kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 

QAWHE ,  3 

BV$LUNCH,KO, AWHEL  SEND  ALL  TO  AWHEL  DURING  LUNCH, 

ELSE  NEXT  BLOCK 

BV$WORKH,Kl, AWHET  SEND  ALL  TO  NEXT  BLOCK  DURING 

WORKING  HOURS,  ELSE  SEND  TO  AWHET 
R$AWHE,K0, AWHEE  SEND  ALL  TO  AWHEE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 
AWHEC , 1PH  LINK  TO  USER  CHAIN  AWHEC 

PI, K4, AWHEA  SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  AWHEA 

3 ,K11  ASSIGN  PROGRESS  PARAMETER 

QAWHE, 3  REMOVE  FROM  QAWHE 

, DUTSC  SEND  HI  PRI  REQS  TO  DUTSC 

1  DUMMY 

, AWHEL  SEND  ALL  TO  AWHEL 


3  ,K11 
QAWHE , 3 
,  DUTSC 
1 

, AWHEL 
AWHE 
OAWHE , 3 
VSAWHES 
AWHE 

BV$WORKH , K1 , AWHT 
AWHEC , AWHEE , 1 , BACK 


AWHT  TEST  NE  P8,K1,DEEXQ 


TEST  E  BV$BEAR , KO , TERM 


ASSIGN  4 , FNSFSIX 

ASSIGN  5 , V$AWHEW 

TEST  G  V$TIME , 1450 , AQUE 


TEST  GE  PI, K4, AQUE 


ASSIGN 


3  ,K17 


TRANSFER  , DUTSC 


AQUE  QUEUE 
ALINK  LINK 


QBTRN , 3 
ACH , 1PH 


PICK  AND  BIN  MATERIAL 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  AWHT 
RELEASE  ONE  TRANSACTION  FROM  AWHEC 

SEND  WAREHOUSE  REFUSALS  TO 
EXCEPTION  HANDLING 

SEND  BEARER  ISSUES  TO  TERM,  ALL 
OTHERS  TO  NEXT  BLOCK 

ASSIGN  ISSUE  DESTINATION 
ASSIGN  ISSUE  WEIGHT 

IF  LAST  TRACTOR  TRAIN  OF  DAY  HAS 
DEPARTED,  SEND  TO  NEXT  BLOCK,  ELSE 
AQUE 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  AQUE 

ASSIGN  PROGRESS  PARAMETER 

TRANSFER  ALL  TO  DUTSC 


PLACE  TRANSACTIONS  ON  A  USER  CHAIN 
AWAITING  ON-BASE  TRANSPORTATION 


% 


*  *  *  *  *  *  *  XX 


**B  WAREHOUSE  AREA  (B-34  ,  B-45  , B-46)  **^f*«**^f****^c^,*c3*r5^^f****,*c3*c3*c^^^***^f:^*^*^* 


BWHEQ  QUEUE  QBWHE , 3 

TEST  E  BV$LUNCH , KO , BWHEL 

TEST  E  BVSWORKH , K1 , BWHET 

TEST  E  R$BWHE , KO , BWHEE 

BWHEL  LINK  BWHEC, 1 PH 

BWHET  TEST  GE  P1(K4,BWHEA 

ASSIGN  3 ,K12 

DEPART  QBWHE , 3 

TRANSFER  (DUTSC 

BWHEA  ADVANCE  1 

TRANSFER  , BWHEL 

BWHEE  ENTER  BWHE 

DEPART  QBWHE, 3 

BWHE  ADVANCE  VSBWHES 

LEAVE  BWHE 

TEST  E  BVSWORKH, K1,BWHT 

UNLINK  BWHEC , BWHEE , 1 , BACK 

BWHT  TEST  ME  P8,K1,DEEKQ 


TEST  E  BV$BEAR , KO , TERM 


ASSIGN  4 , FNSFSEVE 

ASSIGN  5 , VSBWHEW 

TEST  G  V$TIME , 1433 , BQUE 


TEST  GE  PI, u4, BQUE 


ASSIGN  3 ,K18 

* 

TRANSFER  ,DUTSC 

■k 

BOUE  QUEUE  QBTRN, 3 

.BLINK  LINK  BCH,1PH 


SEND  ALL  TO  BWHEL  DURING  LUNCH, 

ELSE  NEXT  BLOCK 

SEND  ALL  TO  NEXT  BLOCK  DURING 

WORKING  HOURS,  ELSE  SEND  TO  BWHET 

SEND  ALL  TO  BWHEE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

LINK  TO  USER  CHAIN  BWHEC 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  BWHEA 

ASSIGN  PROGRESS  PARAMETER 

REMOVE  FROM  QBWHE 

SEND  HI  PRI  REQS  TO  DUTSC 

DUMMY 

SEND  ALL  TO  BWHEL 


PICK  AND  STAGE  MATERIAL 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  BWHT 
RELEASE  ONE  TRANSACTION  FROM  BWHEC 

SEND  WAREHOUSE  REFUSALS  TO 
EXCEPTION  HANDLING 

SEND  BEARER  ISSUES  TO  TERM,  ALL 
OTHERS  TO  NEXT  BLOCK 

ASSIGN  ISSUE  DESTINATION 
ASSIGN  ISSUE  WEIGHT 

IF  LAST  TRACTOR  TRAIN  OF  DAY  HAS 
DEPARTED,  SEND  TO  NEXT  BLOCK,  ELSE 
BOUE 

SEND  HI  PRI  REOS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  BQUE 

ASSIGN  PROGRESS  PARAMETER 

TRANSFER  ALL  TO  DUTSC 


PLACE  TRANSACTIONS  ON  A  USER  CHAIN 
AWAITING  ON-BASE  TRANSPORTATION 


*  * 


^ 57****************************************************************** 


MAINQ  QUEUE  QMAIN, 3 

TEST  E  BV$LUNCH,KO,MAINL 

k 

TEST  E  BV$WORKH , K1 , MAINT 

TEST  E  R$MAIN,K0, MAINE 

■k 

MAINL  LINK  MAINC, 1PH 

^MAINT  TEST  GE  PI, K4, MAINA 

ASSIGN  3 , K13 

DEPART  QMAIN, 3 

TRANSFER  ,DUTSC 

MAINA  ADVANCE  1 

TRANSFER  , MAINL 

MAINE  ENTER  MAIN 

DEPART  QMAIN, 3 

MAIN  ADVANCE  VSMAINS 

LEAVE  .  MAIN 
TEST  E  BVSWORKH , K1 , TMAIN 

UNLINK  MAINC , MAINE , 1 ,BACK 

* 

^TMAIN  TEST  NE  P8,K1,DEEXQ 

TEST  E  BV$BEAR , KO , TERM 


ASSIGN  4 , FNSFEIGH 

ASSIGN  5 , V$MAINW 

TEST  G  V$TIME , 1410 ,MQUE 


TEST  GE  PI , K4 ,MQUE 


ASSIGN  3 , K19 

TRANSFER  ,DUTSC 

MQUE  QUEUE  QATRN , 3 

ML INK  LINK  MCH,1PH 


SEND  ALL  TO  MAINL  DURING  LUNCH, 

ELSE  NEXT  BLOCK 

SEND  ALL  TO  NEXT  BLOCK  DURING 

WORKING  HOURS,  ELSE  SEND  TO  MAINT 

SEND  ALL  TO  MAINE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

LINK  TO  USER  CHAIN  MAINC 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  MAINA 

ASSIGN  PROGRESS  PARAMETER 

REMOVE  FROM  QMAIN 

SEND  HI  PRI  REQS  TO  DUTSC 

DUMMY 

SEND  ALL  TO  MAINL 


PICK  AND  STAGE  MATERIAL 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  TMAIN 
RELEASE  ONE  TRANSACTION  FROM  MAINC 

SEND  WAREHOUSE  REFUSALS  TO 
EXCEPTION  HANDLING 

SEND  BEARER  ISSUES  TO  TERM,  ALL 
OTHERS  TO  NEXT  BLOCK 

ASSIGN  ISSUE  DESTINATION 
ASSIGN  ISSUE  WEIGHT 

IF  LAST  TRACTOR  TRAIN  OF  DAY  HAS 
DEPARTED,  SEND  TO  NEXT  BLOCK,  ELSE 
MQUE 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  MQUE 

ASSIGN  PROGRESS  PARAMETER 

TRANSFER  ALL  TO  DUTSC 


PLACE  TRANSACTIONS  ON  A  USER  CHAIN 
AWAITING  ON-BASE  TRANSPORTATION 


85 


*  *  *  *  XX  XX 


**p  WAREHOUSE  AREA  (F-8  ~  )****************************************** 


FWHEQ 

QUEUE 

QFWHE , 3 

k 

TEST  E 

BVSLUNCH , KO , FWHEL 

* 

TEST  E 

BVSWORKH , K1 , FWHET 

* 

TEST  E 

R$ FWHE, KO, FWHEE 

FWHEL 

LINK 

FWHEC , 1PH 

FWHET 

TEST  GE 

PI, K4, FWHEA 

ASSIGN 

3 ,  K14 

DEPART 

QFWHE , 3 

TRANSFER 

, DUTSC 

FWHEA 

ADVANCE 

1 

TRANSFER 

, FWHEL 

FWHEE 

ENTER 

FWHE 

DEPART 

QFWHE, 3 

FWHE 

ADVANCE 

VS FWHE S 

LEAVE 

FWHE 

* 

TEST  E 

BVSWORKH, Kl, FWHT 

k 

UNLINK 

FWHEC, FWHEE, 1 , BACK 

FWHT 

* 

TEST  NE 

P8 , K1 , DEEXQ 

* 

* 

TEST  E 

BV$BEAR , KO , TERM 

k 

k 

ASSIGN 

4 , FNSFNINE 

k 

ASSIGN 

5 , VSFWHEW 

k 

TEST  G 

VSTIME, 1410, FQUE 

k 

k 

TEST  GE 

PI,  K4, FQUE 

k 

k 

ASSIGN 

3 ,  K20 

k 

TRANSFER 

,  DUTSC 

FOUE 

FLIMK 

QUEUE 

QATRN , 3 

LINK 

FCH , 1PH 

SEND  ALL  TO  FWHEL  DURING  LUNCH, 

ELSE  NEXT  BLOCK 

SEND  ALL  TO  NEXT  BLOCK  DURING 

WORKING  HOURS,  ELSE  SEND  TO  FWHET 

SEND  ALL  TO  FWHEE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

LINK  TO  USER  CHAIN  FWHEC 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  FWHEA 

ASSIGN  PROGRESS  PARAMETER 

REMOVE  FROM  QFWHE 

SEND  HI  PRI  REQS  TO  DUTSC 

DUMMY 

SEND  ALL  TO  FWHEL 


PICK  AND  STAGE  MATERIAL 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  FWHT 
RELEASE  ONE  TRANSACTION  FROM  FWHEC 

SEND  WAREHOUSE  REFUSALS  TO 
EXCEPTION  HANDLING 

SEND  BEARER  ISSUES  TO  TERM,  ALL 
OTHERS  TO  NEXT  BLOCK 

ASSIGN  ISSUE  DESTINATION 

ASSIGN  ISSUE  WEIGHT 

IF  LAST  TRACTOR  TRAIN  OF  DAY  HAS 
DEPARTED,  SEND  TO  NEXT  BLOCK,  ELSE 
FOUE 

SFND  HI  PRI  REOS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  FQUE 

ASSIGN  PROGRESS  PARAMETER 

TRANSFER  ALL  TO  DUTSC 


PLACE  TRANSACTIONS  ON  A  USER  CHAIN 
AWAITING  ON-BASE  TRANSPORTATION 


*  *  *  *  *  *  *  X  *  XX 


**J  WAREHOUSE  AREA  (J-11,J-12  AND  GAS,  LUMBER  AND  DRUM  YARDS ) ************ 


JWHEQ  QUEUE  QJWHE , 3 

TEST  E  BVSLUNCH , KO , JWHEL 

* 

TEST  E  BV$WORKH , K1 , JWHET 

TEST  E  R$ JWHE , KO , JWHEE 

* 

JWHEL  LINK  JWHEC , 1PH 

JWHET  TEST  GE  PI, K4, JWHEA 

* 

ASSIGN  3 ,K15 

DEPART  QJWHE, 3 

TRANSFER  ,DUTSC 

JWHEA  ADVANCE  1 

TRANSFER  , JWHEL 

JWHEE  ENTER  JWHE 

DEPART  QJWHE , 3 

JWHE  ADVANCE  VSJWHES 

LEAVE  JWHE 

TEST  E  BV$WORKH,Kl , JWHT 

* 

UNLINK  JWHEC, JWHEE, 1, BACK 
*JWHT  TEST  NE  P8,K1,DEEXQ 

TEST  E  BV$BEAR , KO , TERM 


ASSIGN  4,FN$FTEN 

ASSIGN  5 , V$JWHEW 

TEST  G  V$TIME , 1410 , JQUE 


TEST  GE  PI ,K4 , JQUE 


ASSIGN  3 , K21 
TRANSFER  ,DUTSC 


JQUE  QUEUE  QBTRN, 3 

JLINK  LINK  JCH , 1PH 


SEND  ALL  TO  JWHEL  DURING  LUNCH, 

ELSE  NEXT  BLOCK 

SEND  ALL  TO  NEXT  BLOCK  DURING 

WORKING  HOURS,  ELSE  SEND  TO  JWHET 

SEND  ALL  TO  JWHEE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

LINK  TO  USER  CHAIN  JWHEC 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  JWHEA 

ASSIGN  PROGRESS  PARAMETER 

REMOVE  FROM  QJWHE 

SEND  HI  PRI  REQS  TO  DUTSC 

DUMMY 

SEND  ALL  TO  JWHEL 


PICK  AND  STAGE  MATERIAL 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  JWHT 
RELEASE  ONE  TRANSACTION  FROM  JWHEC 

SEND  WAREHOUSE  REFUSALS  TO 
EXCEPTION  HANDLING 

SEND  BEARER  ISSUES  TO  TERM,  ALL 
OTHERS  TO  NEXT  BLOCK 

ASSIGN  ISSUE  DESTINATION 

ASSIGN  ISSUE  WEIGHT 

IF  LAST  TRACTOR  TRAIN  OF  DAY  HAS 
DEPARTED,  SEND  TO  NEXT  BLOCK,  ELSE 
JQUE 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  JQUE 

ASSIGN  PROGRESS  PARAMETER 

TRANSFER  ALL  TO  DUTSC 


PLACE  TRANSACTIONS  ON  A  USER  CHAIN 
AWAITING  ON-BASE  TRANSPORTATION 
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kkkkkk'kkkkk-kkkkkkkkkkkkkk'kkkkkkkkkkkkkkkkkkkkkk'k'kkkkk'kkkkk-k’kkkkkkkkkkk 
**  PROVISIONS  TRACTOR  TRAIN  DELIVERY  ** 

**  IN  ACTUAL  NSD  YOKOSUKA  OPERATIONS,  SPECIAL  TRACTOR  TRAIN  RUNS  ** 
**  ARE  SCHEDULED  TO  MEET  OPERATIONAL  REQUIREMENTS  OF  THE  ** 

**  REQUISITIONER.  THESE  SPECIAL  RUNS  ARE  TYPICALLY  SCHEDULED  AFTER  ** 
**  NORMALLY  SCHEDULED  RUNS  ARE  COMPLETED.  THOUGH  THE  SCHEDULE  IS  NOT** 
**  FIXED,  IN  THE  INTEREST  OF  MAINTAINING  ACCURATE  THROUGHPUT  STATS,  ** 
**  A  PROVISIONS  TRACTOR  TRAIN  IS  SCHEDULED  FOR  1600  EACH  DAY,  WITH  ** 
**  A  SECOND  RUN  AT  USER  DISCRETION.  ALL  HIGH  PRIORITY  ISSUES  THAT  ** 
**  ARRIVE  AFTER  1530  ARE  ROUTED  TO  THE  DUTY  SECTION  MODULE.  THE  ** 
**  PROVISIONS  TRACTOR  TRAIN  SCHEDULE  CONTROL  SECTION  IS  PARTIONED  ** 
**  AT  THE  TOP  OF  THE  MODULE.  ** 

* *****  Ik*********** ********* ****** £****** ********** A******************* 
* 

** SCHEDULE  CONTROL  SECTION*************************** ***************** 


GENERATE 

2400, ,1600 

GENERATE  CONTROL  TRANSACTION 

k 

k 

TEST  NE 

BV$WKDAY,K1, SPLTP 

REPRESENTING  DAILY  TRACTOR 

TRAIN  FOR  PROVISIONS  AT  1600 

SEND  TRAIN  TO  SPLTP  IF  WORKDAY, 

k 

TERMINATE 

. 

ELSE  NEXT  BLOCK 

TERMINATE  CONTROL  TRANSACTION 

SPLTP 

SPLIT 

1, LOADP 

SPLIT  CONTROL  TRANSACTION,  SEND 

k 

k 

ADVANCE 

10 

ONE  COPY  TO  NEXT  BLOCK  AND  ONE  TO 
LOADP 

DUMMY  ADVANCE  TO  SEPARATE  TRAINS 

TEST  L 

V$PWGHT , V$PXTRA , LOADP 

k 

k 

k 

k 

k 

TERMINATE 

IF  THE  ESTIMATED  WEIGHT  OF 

ISSUES  WAITING  FOR  THE  PTRN 

EXCEEDS  PXTRA ,  SEND  TO  LOADP, 

ELSE  NEXT  BLOCK 

TERMINATE  CONTROL  TRANSACTION 

LOADP 

UNLINK 

PTRNC , PTRNT , ALL , BACK 

UNLINK  ALL  TRANSACTIONS  FROM  PTRNC 

k 

SAVEVALUE 

PNUM+ , 1 , XF 

TO  PTRNT 

COUNT  PTRN  RUNS 

TERMINATE  TERMINATE  CONTROL  TRANSACTION 

^OPERATIONS  SECTION************************************************** 

k 

PTRMQ 

TEST  G 

V$TIME, 1610, PQUE 

IF  LAST  TRACTOR  TRAIN  OF  DAY  HAS 

k 

k 

TEST  GE 

PI, K4, PQUE 

DEPARTED,  SEND  TO  NEXT  BLOCK,  ELSE 
PQUE 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

k 

k 

ALL  OTHERS  TO  PQUE 

k 

ASSIGN 

3 ,  K16 

ASSIGN  PROGRESS  PARAMETER 

k 

TRANSFER 

, DUTSC 

TRANSFER  ALL  TO  DUTSC 

PQUE 

QUEUE 

QPTRN ,  3 

PLINK 

LINK 

PTRNC, 1PH 

PLACE  TRANSACTIONS  ON  A  USER  CHAIN 

k 

PTRNT 

TEST  L 

R$PTRN , P  5 , PTRNE 

AWAITING  ON-BASE  TRANSPORTATION 

IF  THERE  IS  SUFFICIENT  REMAINING 

k 

k 

TEST  LE 

P1,K3, PTRNE 

CAPACITY  IN  PTRN  SEND  TO  PTRNE, 
ELSE  NEXT  BLOCK 

SEND  HI  PRI  ISSUES  TO  PTRNE,  ALL 

k 

ADVANCE 

1 

OTHERS  TO  NEXT  BLOCK 

DUMMY  ADVANCE 

TRANSFER 

, PLINK 

TRANSFER  ALL  BACK  TO  PLINK 

PTRNE 

ENTER 

PTRM , PH5 

DEPART 

ADVANCE 

LEAVE 

TRANSFER 

^PTRN , 3 

PTRN, PH5 
, FRTTE 

TRANSPORTATION  DELAY  TO  J-39 

TRANSFER  ALL  TO  FRTTE 
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fc**********:*********:**************************:*****;*:***  *************** 

**  TRACTOR  TRAIN  DELIVERY  ** 

**  CONTROL  TRANSACTIONS  REPRESENTING  NSD-OPERATED  TRACTOR  TRAINS  ** 
**  ARE  GENERATED  AT  0815,1015,1300,1400.  ON  WORKDAYS,  THE  ** 

**  TRANSACTIONS  ARE  ROUTED  TO  UNLINK  MATERIAL  TRANSACTIONS  WAITING  ** 
**  ON  THE  VARIOUS  WAREHOUSE  USER  CHAINS.  MATERIAL  TRANSACTIONS  ARE  ** 
**  LINKED  TO  THE  ATRNC  OR  BTRNC ,  AS  APPROPRIATE,  TO  THE  CAPACITY  OF  ** 
**  THE  RESPECTIVE  TRAINS  REMAINING  AT  EACH  STOP.  TRANSACTIONS  ARE  ** 
**  THEN  UNLINKED  AND  MATERIAL  REQUISITIONED  BY  SRF  OR  PWC  IS  SENT  TO** 
**  TERMINATION  TO  SIMULATE  DELIVERY.  ALL  OTHER  ISSUES  ARE  UNLINKED  ** 

**  TO  THE  FREIGHT  TERMINAL  MODULE.  HIGH  PRIORITY  TRANSACTIONS  THAT  ** 

**  MISS  THE  LAST  SCHEDULED  TRAIN  ARE  SENT  TO  THE  DUTY  SECTION  ** 

**  MODULE.  AT  USER  DISCRETION,  AN  ADDITIONAL  TRAIN  MAY  BE  RUM  ON  ** 
**  EACH  ROUTE  AT  1500  TO  REDUCE  BACKLOG.  THE  TRACTOR  TRAIN  SCHEDULE  ** 
**  CONTROL  SECTION  IS  PARTIONED  AT  THE  TOP  OF  THE  MODULE.  ** 

•k  k  *  -k  k  -k  k  *  -k  k  k  k  *  *  *  *  *  *  *  *  *  *  k  *  *  *  k  *  k  k  k  *  *  *  k  *  k  k  *  *  *  k  k  *  k  k  *  *  k  k  *  k  k  k  *  *  *  k  k  *  *  k  k  *  k  *  k  *  *  k 
k 

kk SCHEDULE  CONTROL  SECTION******************************************** 

k 

GENERATE  2400,, 825  GENERATE  CONTROL  TRANSACTION 

*  REPRESENTING  0815  TRAINS 

TRANSFER  , TRAIN  SEND  TO  WAREHOUSES  ON  ROUTE 

GENERATE  2400,, 1025  GENERATE  CONTROL  TRANSACTION 

*  REPRESENTING  1015  TRAINS 

TRANSFER  , TRAIN  SEND  TO  WAREHOUSES  ON  ROUTE 

■k 

GENERATE  2400 , , 1300  GENERATE  CONTROL  TRANSACTION 

*  REPRESENTING  1300  TRAINS 

TRANSFER  , TRAIN  SEND  TO  WAREHOUSES  ON  ROUTE 

* 

GENERATE  2400 , , 1400  GENERATE  CONTROL  TRANSACTION 

*  REPRESENTING  1400  TRAINS 

TRANSFER  , TRAIN  SEND  TO  WAREHOUSES  ON  ROUTE 

* 

GENERATE  2400,, 1500  GENERATE  CONTROL  TRANSACTION 

*  REPRESENTING  1500  TRAINS 

TEST  E  BVSWKDAY , K1 , TTTRM  ON  WORKDAYS,  SEND  TO  NEXT  BLOCK 

SPLIT  1 , LATEB  SPLIT  CONTROL  TRANSACTION 

TEST  L  V$AWGHT , V$AXTRA , LOADA 

*  IF  THE  ESTIMATED  WEIGHT  OF 

*  ISSUES  WAITING  FOR  THE  ATRN 

*  EXCEEDS  AXTRA ,  SEND  TO  LOADA, 

*  ELSE  NEXT  BLOCK 

TERMINATE  TERMINATE  CONTROL  TRANSACTION 


TERMINATE 


LATEB  TEST  L 


TERMINATE 


V$BWGHT , V$BXTRA , LOADB 


IF  THE  ESTIMATED  WEIGHT  OF 
ISSUES  WAITING  FOR  THE  BTRN 
EXCEEDS  BXTRA ,  SEND  TO  LOADB, 
ELSE  NEXT  BLOCK 
TERMINATE  CONTROL  TRANSACTION 


TRAIN  TEST  NE 
TTTRM  TERMINATE 


BV$WKDAY , K1 , LOAD 


SEND  TRAIN  TO  LOAD  IF  WORKDAY 
TERMINATE  CONTROL  TRANSACTION 


LOAD  SPLIT 


1 , LOADB 


SPLIT  CONTROL  TRANSACTION,  SEND 
ONE  COPY  TO  NEXT  BLOCK  AND  ONE  TO 
LOADB 


**LOADING  SECTION  **************************************************** 
* 


LOADA 

UNLINK 

MCH , ATEST , ALL , BACK 

UNLINK  ALL  TRANSACTIONS 

FROM 

MCH 

* 

UNLINK 

FCH, ATEST, ALL, BACK 

TO  ATRNT 

UNLINK  ALL  TRANSACTIONS 

FROM 

FCH 

k 

ADVANCE 

17 

TO  ATRNT 

SIMULATE  TRANSPORTATION 

TIME 

TO 

k 

UNLINK 

MCH, ATRNT, ALL, BACK 

F  WAREHOUSE  AREA 

UNLINK  ALL  TRANSACTIONS 

FROM 

MCH 

k 

UNLINK 

FCH,ATRNT, ALL, BACK 

TO  ATRNT 

UNLINK  ALL  TRANSACTIONS 

FROM 

FCH 

k 

ADVANCE 

32 

TO  ATRNT 

SIMULATE  TRANSPORTATION 

TIME 

TO 

k 

UNLINK 

ATRNC , ATRNL , ALL , BACK 

PWC/SRF 

UNLINK  ALL  TRANSACTIONS 

FROM 

ATRNC 

k 

k 

SAVEVALUE 

TERMINATE 

ANUM+,1 ,XF 

TO  ATRNL 

COUNT  ATRN  RUNS 

TERMINATE  CONTROL  TRANSACTION 

LOADB 

UNLINK 

JCH,BTEST, ALL, BACK 

UNLINK  ALL  TRANSACTIONS 

FROM 

JCH 

* 

UNLINK 

BCH,BTEST, ALL, BACK 

TO  BTEST 

UNLINK  ALL  TRANSACTIONS 

FROM 

BCH 

k 

UNLINK 

ACH,BTEST, ALL, BACK 

TO  BTEST 

UNLINK  ALL  TRANSACTIONS 

FROM 

ACH 

k 

ADVANCE 

8 

TO  BTEST 

SIMULATE  TRANSPORTATION 

TIME 

TO 

k 

UNLINK 

JCH,BTRNT, ALL, BACK 

J  WAREHOUSE  AREA 

UNLINK  ALL  TRANSACTIONS 

FROM 

JCH 

k 

ADVANCE 

3 

TO  BTRNT 

SIMULATE  TRANSPORTATION 

TIME 

TO 

k 

UNLINK 

BCH,BTRNT, ALL, BACK 

B  WAREHOUSE  AREA 

UNLINK  ALL  TRANSACTIONS 

FROM 

BCH 

k 

ADVANCE 

10 

TO  BTRNT 

SIMULATE  TRANSPORTATION 

TIME 

TO 

k 

UNLINK 

ACH,BTRNT, ALL, BACK 

A  WAREHOUSE  AREA 

UNLINK  ALL  TRANSACTIONS 

FROM 

ACH 

k 

ADVANCE 

17 

TO  BTRNT 

SIMULATE  TRANSPORTATION 

TIME 

TO 

k 

UNLINK 

BTRNC,BTRNL, ALL, BACK 

PWC/SRF 

UNLINK  ALL  TRANSACTIONS 

FROM 

BTRNC 

k 

SAVEVALUE 

TERMINATE 

BNUM+ , 1 , XF 

TO  BTRNL 

COUNT  BTRN  RUNS 

TERMINATE  CONTROL  TRANSACTION 
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**OPERATIONS  SECTION  -  A  TRAIN  ROUTE********************************** 


ATEST 

TEST  G 

PI ,K1, ASEND 

ATRNT 

TEST  L 

R$ ATRN, P5, ATRNE 

ASEND 

ADVANCE 

1 

TRANSFER 

FN , FTHFR 

ATRNE 

ENTER 

ATRN, PH 5 

DEPART 

QATRN , 3 

LINK 

ATRNC, 1 PH 

ATRNL 

LEAVE 

ATRN , PH5 

TRANSFER 

, TMTST 

SEND  IPG3  ISSUES  TO  ASEND,  ALL 

OTHERS  TO  NEXT  BLOCK 

IF  THERE  IS  SUFFICIENT  REMAINING 

CAPACITY  IN  ATRN  SEND  TO  ATRNE , 

ELSE  NEXT  BLOCK 

DUMMY  ADVANCE 

TRANSFER  ALL  BACK  TO  WAREHOUSE 


LINK  TO  ATRNC 
TRANSFER  ALL  TO  TMTST 


**OPERATIONS  SECTION  -  B  TRAIN  ROUTE********************************** 

k 


BTEST 

k 

TEST  G 

PI, Kl, BSEND 

SEND  IPG3  ISSUES  TO  BSEND,  ALL 
OTHERS  TO  NEXT  BLOCK 

BTRNT 

* 

k 

TEST  L 

R$BTRN,P5, BTRNE 

IF  THERE  IS  SUFFICIENT  REMAINING 
CAPACITY  IN  BTRN  SEND  TO  BTRNE, 
ELSE  NEXT  BLOCK 

BSEND 

ADVANCE 

1 

DUMMY  ADVANCE 

TRANSFER 

FN , FTHFV 

TRANSFER  ALL  BACK  TO  WAREHOUSE 

BTRNE 

ENTER 

BTRN , PH5 

DEPART 

QBTRN , 3 

LINK 

BTRNC, 1PH 

'LINK  TO  BTRNC 

BTRNL 

LEAVE 

BTRN, PH 5 

**TEST 

X 

FOR  PWC/PRF  DELIVERY******************************************* 

TMTST  TEST  NE  P4,K1,TERM 

* 
k 

k 


SEND  ISSUES  FOR  SRF  AMD  PWC  TO 
TERM  TO  SIMULATE  DELIVERY  BY 
TRACTOR  TRAIN,  ALL  OTHERS  TO  NEXT 
SIMULATE  TRANSPORTATION  TIME  TO 
FREIGHT  TERMINAL 


ADVANCE 


17 
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**  FREIGHT  TERMINAL  MODULE 

**  TRANSACTIONS  REPRESENTING  MATERIAL  ARE  TESTED  FOR  PACK  TYPE 
**  REQUIRED  AND  SENT  TO  LIGHT  OR  HEAVY  PACK  LINES  AS  APPROPRIATE 
**  (PARCEL  POST  PACKS  GO  TO  THE  LIGHT  PACK  LINE).  PACK  TIMES 
**  IN  THE  LIGHT  PACK  LINE  ARE  OBTAINED  FROM  FUNCTION  FTWSV.  AFTER 
**  PACKING  IS  COMPLETED,  ALL  ISSUES  ARE  ROUTED  TO  THE  TERMINATION 
**  MODULE  AS  AVAILABLE  FOR  SHIPMENT.  MATERIAL  RECEIVED  FROM  TRACTOR  ** 
**  TRAINS  THAT  DOES  NOT  REQUIRE  PACKING  IS  SENT  DIRECTLY  TO  THE  ** 
**  TERMINATION  MODULE  AS  AVAILABLE  FOR  SHIPMENT.  ** 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 
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kk 

kk 


FRTTE  TEST  E 


P4,K2,TERM 


TRANSFER  .  V$LITEP , , LITPQ 


SEND  ISSUES  AVAILABLE  FOR  SHIPMENT 
SHIPMENT  TO  TERM,  ALL  OTHERS  TO 
NEXT  BLOCK 

TRANSFER  ISSUES  REQUIRING  LIGHT  OR 
PARCEL  POST  PACK  TO  LITEQ,  ALL 
OTHERS  TO  NEXT  BLOCK 


k 
k 
k 

k 
k 
k 

**HEAVY  PACK  OPERATIONS  SECTION***********5*'******************'*''*'******* 
* 


HVYPQ 

QUEUE 

QHVYP , 3  ■ 

TEST  E 

BV$LUNCH,KO, HVYPL 

SEND  ALL  TO  HVYPL  DURING  LUNCH, 
ELSE  NEXT  BLOCK 

TEST  E 

BV$WORKH,Kl, HVYPT 

SEND  ALL  TO  NEXT  BLOCK  DURING 
WORKING  HOURS,  ELSE  SEND  TO  HVYPT 

TEST  E 

R$HVYP,K0, HVYPE 

SEND  ALL  TO  HVYPE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

HVYPL 

LINK 

HVYPC, 1PH 

LINK  TO  USER  CHAIN  HVYPC 

HVYPT 

TEST  GE 

P1,K4, HVYPA 

SEND  HI  PRI  REOS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  HVYPA 

ASSIGN 

3  ,K22 

ASSIGN  PROGRESS  PARAMETER 

DEPART 

QHVYP , 3 

REMOVE  FROM  QHVYP 

TRANSFER 

, DUTSC 

SEND  HI  PRI  REQS  TO  DUTSC 

HVYPA 

ADVANCE 

1 

DUMMY 

TRANSFER 

, HVYPL 

SEND  ALL  TO  HVYPL 

HVYPE 

ENTER 

DEPART 

HVYP 

QHVYP , 3 

HVYP 

ADVANCE 

LEAVE 

VSHVYPS 

HVYP 

PACK  MATERIAL  REQUIRING  HEAVY  PACK 

TEST  E  BV$WORKH,Kl, HVYTR  DURING  WORKING  HOURS  SEND  ALL  TO 

NEXT  BLOCK,  ELSE  TO  HVYTR 

UNLINK  HVYPC , HVYPE , 1 , BACK  RELEASE  ONE  TRANSACTION  FROM  HVYPC 

HVYTR  TRANSFER  , TERM 


**LIGHT  AND  PARCEL  POST  PACK  OPERATIONS  SECTION*********************** 


LITPQ  QUEUE  QLITP,3 

*  TEST  E  BV$LUNCH , KO , LITPL 

^  TEST  E  BV$WORKH , K1 , LITPT 

^  TEST  E  R$LITP ,KQ ,LITPE 

LITPL  LINK  LITPC , 1PH 

^LITPT  TEST  GE  PI, K4, LITPA 

ASSIGN  3 ,K23 

DEPART  QLITP , 3 

TRANSFER  ,DUTSC 

LITPA  ADVANCE  1 

TRANSFER  ,  LITPL 

LITPE  ENTER  LITP 

DEPART  QLITP, 3 

^LITP  ADVANCE  VSLITPS 

LEAVE  LITP 

k  test  E  BV$WORKH,Kl ,littr 

UNLINK  LITPC, LITPE, 1 , BACK 

LITTR  TRANSFER  .TERM 


SEND  ALL  TO  LITPL  DURING  LUNCH, 

ELSE  NEXT  BLOCK 

SEND  ALL  TO  NEXT  BLOCK  DURING 

WORKING  HOURS,  ELSE  SEND  TO  LITPT 

SEND  ALL  TO  LITPE  IF  STORAGE  IS 

NOT  FULL,  ELSE  NEXT  BLOCK 

LINK  TO  USER  CHAIN  LITPC 

SEND  HI  PRI  REQS  TO  NEXT  BLOCK, 

ALL  OTHERS  TO  LITPA 

ASSIGN  PROGRESS  PARAMETER 

REMOVE  FROM  QLITP 

SEND  HI  PRI  REQS  TO  DUTSC 

DUMMY 

SEND  ALL  TO  LITPL 


PACK  MATERIAL  REQUIRING  LIGHT  OR 
PARCEL  POST  PACK 

DURING  WORKING  HOURS  SEND  ALL  TO 
NEXT  BLOCK,  ELSE  TO  LITTR 
RELEASE  ONE  TRANSACTION  FROM  LITPC 


********************************************************************** 
**  DUTY  SECTION  ** 

**  THE  SCHEDULE  CONTROL  SECTION  GENERATES  A  CONTROL  TRANSACTION  AT  ** 
**  AT  THE  START  OF  EACH  DAY  TO  CONTROL  DUTY  SECTION  OPERATIONS.  ON  ** 
**  WORKDAYS,  ADVANCE  BLOCKS  MOVE  THE  TRANSACTION  THRU  THE  SCHEDULE  ** 
**  CONTROL  SECTION.  AT  APPROPRIATE  TIMES,  THE  STORAGE  REPRESENTING  ** 
**  THE  DUTY  SECTION  IS  OPENED  AND  CLOSED  AND  TRANSACTIONS  ARE  LINKED** 
**  TO  AND  UNLINKED  FROM  USER  CHAINS  WITHIN  THE  OPERATING  SECTION.  ** 
********************************************************************** 

**  THE  DUTY  SECTION  OPERATIONS  SECTION  SIMULATES  NSD  LATE  SHIFT  AND  ** 
**  DUTY  SECTION  OPERATIONS.  THE  DUTY  STORAGE  HAS  A  CAPACITY  OF  TWO  ** 
**  MATCHING  THE  NUMBER  OF  PERSONNEL  ACTUALLY  AVAILABLE  IN  BOTH  THE  ** 
**  LATE  SHIFT  AND  THE  DUTY  SECTION  TO  PROCESS  ISSUES.  TRANSACTIONS  ** 
**  ENTERING  THE  MODULE  ARE  SPLIT  INTO  THREE  TRANSACTIONS  TO  RESTORE  ** 
**  THE  ACTUAL  DEMAND  LEVEL  AND  ADVANCED  TO  THE  POINT  OF  PROGRESS  ** 
**  INDICATED  BY  P3.  TRANSACTIONS  TRANSFERRED  TO  THE  DUTY  SECTION  ** 
**  BUT  NOT  PROCESSED  ARE  TRANSFERRED  BACK  TO  THEIR  MODULE  OF  ORIGIN.** 
**  COMPLETED  ISSUES  ARE  TERMINATED  AS  APPROPRIATE  (NIS  OR  AVAILABLE  ** 
**  FOR  SHIPMENT).  NOTE:  BECAUSE  MOST  HIGH  PRIORITY  PERISHABLE  ** 

**  PROVISIONS  ISSUES  MADE  OUTSIDE  OF  NORMAL  WORKING  HOURS  BY  NSD  ** 
**  ARE  FOR  FLEET  ACTIVITIES,  YOKOHAMA  COLD  STORAGE  REQUISITIONS  ARE  ** 
**  ROUTED  INSTEAD  TO  YOKOSUKA  COLD  STORAGE.  ** 

********************************************************************** 


**SCHEDULE  CONTROL  SECTION*************************** ** ************* ** 

A 


GENERATE  2400 ,0,1 


GENERATE  CONTROL  TRANSACTION 


TEST  E 

k 

ADVANCE 

UNLINK 

k 

ADVANCE 

UNLINK 

it 

DTEND  TERMINATE 


BV$WKDAY , K1 , DTEND  SEND  TO  DTEND  IF  SAT/SUN  ELSE  NEXT 

BLOCK 

800  ADVANCE  TO  0801 

DUTYC , DUTYD , ALL , BACK  UNLINK  TRANSACTIONS  NOT  PROCESSED 

BY  THE  DUTY  SECTION 
875  ADVANCE  TO  1646 

DUTYC , DUTYS , 2 , BACK  UNLINK  2  TRANSACTIONS  FOR  DUTY 

SECTION  PROCESSING 
TERMINATE  CONTROL  TRANSACTION 


PTWTH  ADVANCE 
SHIP  ASSIGN 
LEAVE 

DUTTR  ADVANCE 
TEST  E 
UNLINK 


FN$FTWSV  LIGHT/PARCEL  POST  PACK 

3 ,K24  TAG  AS  AVAILABLE  FOR  SHIPMENT 

DUTY 

DUMMY  ADVANCE 

BVSTHREE , K1 , SEND 
DUTYC , DUTYS , 1 , BACK 

UNLINK  ONE  TRANSACTION  FROM  DUTYC 
FOR  EVERY  THREE  LEAVING 
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********************************************************************** 
**  TERMINATION  MODULE  ** 

**  IN  THE  TABLE  DEFINITION  SECTION,  FREQUENCY  DISTRIBUTION  TABLES  ** 
**  ARE  DEFINED  TO  MEASURE  THROUGHPUT  TIME  FOR  ALL  ISSUES  (ALL)  AND  ** 
**  BY  ISSUE  PRIORITY  GROUP  ( IPGON , IPGTW , IPGTH) .  TABULATION  OF  ** 

**  ISSUES  IN  APPROPRIATE  TABLES  IS  MANAGED  BY  ROUTING  TRANSACTIONS  ** 
**  BY  PARAMETER  ONE  VALUES.  RAH  COUNTS  ARE  MADE  ON  NIS  AND  ** 

**  WAREHOUSE  REFUSAL  TRANSACTIONS.  ** 

**********************************************;****;******************** 
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SIMULATION  RUN  CONTROL 

THE  FIRST  START  STATEMENT  AND  THE  FOLLOWING  RESET  STATEMENT  ARE 
USED  TO  BRING  THE  MODEL  TO  STEADY  STATE,  THAT  IS,  TO  FILL  IT 
WITH  TRANSACTIONS  SO  THAT  THE  SIMULATION  DOES  NOT  START  WITH  AN 
EMPTY  SUPPLY  DEPOT.  THE  INITIAL  STATEMENT  RESETS  ALL  SAVEVALUES 
USED  TO  GATHER  STATISTICS  DURING  THE  SIMULATION  TO  ZERO.  THE 
FINAL  START  STATEMENT  REFERS  TO  FIRST  TERMINATE  STATEMENT  IN  THE 
MASTER  SCHEDULE  CONTROL  MODULE,  TERMINATING  THE  SIMULATION  WHEN 
THE  4TH  TRANSACTIONS  ENTERS  THAT  BLOCK. 
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